[OJS] When session times out changing tab in a page doesn't move you to login page

[WaDelma]

If session times out and try to switch a tab in a page (eg. being on Distribution Settings on tab Access and moving to tab Payments) message:

The current role does not have access to this operation.

is shown instead of moving user to login page.

[jamshidhashimi]

For this, I propose adding:

// Ensure a logged in user is available
import('lib.pkp.classes.security.authorization.UserRequiredPolicy');
$this->addPolicy(new UserRequiredPolicy($request, 'user.authorization.loginRequired'));

(You can see the UserRequiredPolicy class here)
before

// Ensure we're in a context
import('lib.pkp.classes.security.authorization.ContextRequiredPolicy');
$this->addPolicy(new ContextRequiredPolicy($request, 'user.authorization.noContext'));

in ContextPolicy.inc.php.

This way, at least user understands that the session is either destroyed or expired by seeing Login Required. message. Through Handler.js, a redirect to login page is also possible, but I don't know if that's something we want to do for now.

I tested the functionality and it works fine in my setup.

@asmecher please advice.

[asmecher]

Hi @jamshidhashimi! I'd suggest looking into a little-known feature of the authorization framework -- policy advice. There are a few examples of calls to setAdvice in the codebase (see e.g. lib/pkp/classes/security/authorization/HttpsPolicy.inc.php). I think the UserRequiredPolicy would be a good candidate for another call like this.

There's a related problem worth thinking about: how to handle errors in a way that expects the request's expected response type (JSON vs. HTML). It might be possible to consider that in solving this issue, too. It would permit us to introduce an error handler that behaves better than the current one, which can cause AJAX requests to die without explanation when there's an error.

[jamshidhashimi]

Hi @asmecher. Thank you for the suggestions. It was nice for me to explore the setAdvice method and functionality in the codebase. I wanted to add it in UserRequiredPolicy but noticed that we don't have to, as the constructor in AuthorizationPolicy is handling that part. So only adding the UserRequiredPolicy in the ContextPolicy seems working fine, as I suggested above.

On handling errors, I agree and suggest we explore that further, maybe in a different issue? as for example in the context of this issue, on what to do after the user gets the Login Required message is to choose what is the best next action: to directly redirect, to show a timer and redirect, or to just show options on what to do and let the user to choose, for example either stay or redirect.

[asmecher]

I think that'll work with all the currently coded uses of ContextPolicy, but I could imagine cases where ContextPolicy would be used to ensure that there's a context but where a user login shouldn't be required. Maybe ContextAccessPolicy would be a better fit? That requires at least one role in the current context, so it would presume that a user is present.

[jamshidhashimi]

Hi @asmecher. Currently ContextAccessPolicy is not called when dealing with Submissions. Having the UserRequiredPolicy check in ContextAccessPolicy is only triggered in the Settings section for example. This may need some work to do, to keep things aligned there. For now, as ContextAccessPolicy is extending ContextPolicy, putting UserRequiredPolicy check in the ContextPolicy gets triggered in most of the places.

Considering above, here is the current implementation in my own Fork: i1576-fix

Can you please review?