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
There was a conflict between two repeaters that had the same fieldName (data) bound to the same controller. Example:
Controller: Events
Manages a ReportTemplate model with a custom popup Form widget that uses a grouped repeater with the field name data to define the available "fields" within a ReportTemplate
Also manages Report models through a relation controller that uses a Form widget with a regular repeater with the field name data that defines the values of the fields defined by the associated ReportTemplate.
Since both repeaters had the field name of "data", but one of them was grouped and the other wasn't, this would cause an issue in Repeater::processExistingItems() where the grouped repeater would attempt to process the ungrouped repeater's data which would then fail. This issue could easily cause many other vastly more confusing and difficult to detect issues in cases where multiple repeaters with the same field name AND the same mode (grouped vs regular) existed on the same page under different contexts. The simple solution is just to ensure that the indexInputName and groupInputName are both taking the repeater's alias into account when being generated to ensure that everything stays unique like it should.
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.
Fixes#4046
It is possible that the user model gets fetched using the SoftDelete
trait before the relevant migrations were applied during an update.
To fix this edge case the user model is always fetched using the
withTrashed scope and the deleted_at check is done manually afterwards.
@see https://github.com/octobercms/october/issues/3999
Samuel Georges
Ben Thomson
Tomy Smith
Larry Barker
Luke Towers
Alexander Guth
Sicklou
Ayumi Hamasaki
Mohamed Ali Behiry
BenjaminMINK
fansaien
Panagiotis Koursaris
Ben Thomson
Mahmut Namli
Szabó Gergő
Antonie Hogewoning
Denis Denisov
Farrow
Tobias Kündig
Nathan van der Werf