I have an OJS 3.3.1 installation that goes into an endless redirect loop with any page one tries to open.
After a bit of debugging it turned out that the the method AuthorizationDecisionManager::decide() always returns AUTHORIZATION_DENY (2) for any page request, even for pubicly accessible pages not behind the login barrier; here AUTHORIZATION_PERMIT (1) would be expected. It happens in this line:
This is an especially strange case, as the same project runs fine and returns AUTHORIZATION_PERMIT when expected on our dev instance (Apache on Windows 10) and our previous staging instance (Apache on Ubuntu 20). The problem only occurs on our new staging and production instance (Apache on CentOS 8).
There are no messages in the PHP error log or the server log that would indicate any code errors leading to this behaviour.
Did something like this happen to anyone else or are there any things to look out for that I missed?
Are you sure that’s the correct version number? OJS 3.3.1 has not been released, so that seems strange. Knowing the correct version number may assist our team or other community members in addressing your query.
I can see this is already a very specific problem. What would be a great help, though:
Can anyone give advice on how to best determine which handler’s authorisation policies might trigger the AUTHORIZATION_DENY? Is there a good strategy to figure this out?
It took a while but it I figured out that classes/security/authorization/HttpsPolicy.inc.php causes the AUTHORIZATION_DENY because it detects a request protocol as http while the force_ssl configuration setting is active.
I suppose, this points at some configuration issues with the server’s SSL certificate and this issue can be considered closed.
Yet, I would be interested whether there would be a smarter way to find the policy that denies access. Or perhaps a way to log authorisation rejections.
For anyone having similar problems and stumbling over this thread, here’s a summary of what the problem was.
It turned out our SSL certificate was not correctly configured, which meant that although in the browser URL bar it looked like we’re opening a page with https, that was not the case for the PKPRequest who identified the protocol as http.
Because our configuration setting for force_ssl was On, HttpsPolicy.inc.php checked the request, noted that it was not a secure request and returned AUTHORIZATION_DENY. Together with this, it also returned redirectSSL as AUTHORIZATION_ADVICE_CALL_ON_DENY, which means that the router will call the same URL again via https.
But alas, as our certificate didn’t work properly, this then lead to an endless redirect loop.