For some reason it was decided to allow October controllers to support Laravel middleware, this has been reverted because it is a convoluted solution that doesn't respect the original architecture. There are other ways to handle middleware requirements
The original use case appeared to be to simply allow backend controllers to inject headers. This is something easily solvable whilst keeping the simple and original workflow
Credit to @fansaien. S3 supports generating temporaryUrls to files that don't exist yet so this adds a check to make sure temp URLs are only generated for valid files.
The response is returned directly to the route so this is not needed, it was likely added as an artefact of a previous implementation
Refs #3773
Refs #3746
If a website has a Service Worker installed it would load and register before a User tries to login to the backend causing a "Invalid security token" message. This PR unregisters any installed Service Worker when a User opens the backend Signin webpage.
I have also added the NEW Security Headers to add Protection to October's Cache and Cookies. This includes two new Middleware that first clears any bad cached data before a User tries to login and the second Middleware will clear all the sensitive User Data when a User signs out of the Backend.
For more info on the new Security Header 'Clear Site Data' you can see the spec found here: https://www.w3.org/TR/clear-site-data/Fixes#4076, fixes#3707.
Adds support to retrieve protected files using the class they are defined to be using if that class differs from the default System\Models\File class. This makes it possible to use a custom class extending the base file model class that does output processing on the file data (for example, an EncryptedFile class that has to decrypt the file contents before they can be output to the browser).
Fixes#3315 by moving the manipulation of the filter widget scopes to the controller event method instead of before any part of the controller constructor method is run.
This builds on 4fd1ca824f by switching from a two tier approach to permissions (superusers and regular users), to a three tier approach (superusers (developer), second-in-command (clients with manage_users permissions), and regular users). If support for a four tier approach is necessary (Superuser, Franchise Owner, Franchise Business Manager, Franchise Staff as an example), then it can be implemented simply by adding a flag to roles that would prevent anyone except for a superuser from assigning that role.
The specific changes made by this commit is to support users with the manage_users permission (but who are not superusers) to be able to assign roles to other users and improvements to the sanctity of the superuser itself. Non-superusers can no longer see or edit superusers in the backend (that was previously poorly handled as a non-superuser with manage_users could take over a superuser account since they could modify that account willy-nilly), and the is_superuser filter is accordingly removed as well.
These are roles defined by a special API code, once a system role code is detected, the role becomes locked and its permissions are sourced from the AuthManager. All permissions are granted to system roles by default, unless otherwise specified. This should make it easier to create client accounts as "Publishers", hiding developer tools like the CMS and Builder plugins by default.
