avoid CMS coupling #9830
avoid CMS coupling #9830
Conversation
In the current setup, we cannot use a custom security controller without the cms module. This changes allow setting another controller as "page_class".
| @@ -579,8 +579,13 @@ protected function getResponseController($title) | |||
| $holderPage->URLSegment = 'Security'; | |||
| // Disable ID-based caching of the log-in page by making it a random number | |||
| $holderPage->ID = -1 * random_int(1, 10000000); | |||
|
|
|||
| if ($holderPage instanceof Controller) { | |||
| $controller = $holderPage; | |||
There was a problem hiding this comment.
Should this go a bit higher in the method after the Injector call and move setting the title, url segment and ID into the condition when it's not an instance of a controller? Even though it might work it seems a bit hacky this way.
There was a problem hiding this comment.
I agree. Actually I believe that what would be nice is to set some kind of callback to generate the page. This way this code could be shifted into the CMS module altogether and avoid coupling entirely. But that requires coordinated changes between the framework and CMS module. It's not logical that the security class has knowledge of the page class.
There was a problem hiding this comment.
While I don't disagree with the intention of this PR, I really don't think "reusing" the page_class config which is intended for Pages, with a Controller, is a particularly clean solution
Also fair warning, any pull-requests that are security related are difficult to merge due to the potentially nasty downstream regressions they can cause if we get things wrong.
|
@emteknetnz yes i fully understand. as i said, the page_class should not be in there in the first place because it relies on the cms module to be installed. |
In the current setup, we cannot use a custom security controller without the cms module. This changes allow setting another controller as "page_class".