-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check SecureMode in a Plack middleware #1431
Comments
Also extracting the script_file_name and localising $Kernel::OM are now also done in middlewares.
A first test looked fine. _installer.pl could be accessed for a new installation. After calling bin/docker/quick_setup.pl access is denied. In the latter case the HTTP status is now 403. |
So that they can be treated almost like PSGI applications. Not completely, as the constructor still needs to be called.
This makes it ease to assing middlewares to specific interfaces. otobo.x.script_file_name is no longer needed, as dispatching is done with an URL map. Set $Env->{SERVER_SOFTWARE} in $SetEnvMiddleware, just to avoid jet another middleware
This just feels wrong. Separation of concerns is a good thing.
before the method Content() is called. Because Content() might want to set input params.
Ah, Plack expects middlewares to reside in The interface modules will be outfitted with the method response, thus a interface specifc Plack App will look like:
|
A hopefully final beautification. The interface modules can inherit from Plack::Component, https://metacpan.org/pod/Plack::Component, and
|
Reinstating the previous behavior. Fixing the failure of scripts/test/PSGI/IndexHtml.t
…_mode Issue #1431 middleware secure mode
Looks good so far. Closing this issue. |
Currently the authentication checks are done in the interface modules and possibly in Kernel::GenericInterface::Provider. IMHO, it would be nice to refactor that into nice Plack middlewares. However, this might be a bit tricky. Therefore I propose to do a simple case in an examplar fashion. install.pl and migration.pl only check the SecureMode. Thus this case is an easy case for refactoring.
In order to not make otobo.psgi unmanageable, the new middleware should be a module in Kernel/System/Web/Middlewares.
The text was updated successfully, but these errors were encountered: