seam-faces SecurityPhaseListener behaviour?

[piklos]

Hello,
I upgraded my dependecies to seam version 3.1.0.Final. And some things related to seam-security and viewconfig started behaving differently.
AcessDeniedView redirection is sometimes triggered and sometimes not. By looking at the code i think this is the problem:

  private void redirectToAccessDeniedView(FacesContext context, UIViewRoot viewRoot) {
        // If a user has already done a redirect and rendered the response (possibly in an observer) we cannot do this output
        final PhaseId currentPhase = context.getCurrentPhaseId();
        if (!context.getResponseComplete() && !PhaseId.RENDER_RESPONSE.equals(currentPhase)) {
           ....
   

So because sometimes the current jsf phase is render response, the code that is supposed to do the redirection is skipped.
When i comment that out and ignore the jsf phase, everything works just as it used to work before the upgrade to 3.1.0.Final.

Im just curious how come that the JSF phase is an issue on redirectToAccessDeniedView method, but is not an issue on redirectToLoginPage method.
What's so different in redirecting to a login page?

[piklos]

I forgot to mention that the method i showed is in the SecurityPhaseListener.

I also forgot to mention that application is being deployed to tomcat 7 (I do not beleive that it has anything to do with this).
I use primeface,richfaces,pretyfaces (3.3.2).

[blabno]

I'm having similar problems. As a workaround I add

@RestrictAtPhase(PhaseIdType.RESTORE_VIEW)

to each page I have security binding annotation, but I would prefer not have to do it. I consider this as a bug.
Let's see what Jason says.

[piklos]

Thanks for the hint. Documentation mentions

@RestrictAtView

annotation, but i think that that should be

@RestrictAtPhase

(as you said).
It also seems to say that it is possible to put that annotation on top of the interface, and then all of the pages would be checked at that particular phase.

I still wonder why is there a problem redirecting in the render response phase??? And even more so, why is that a problem only with redirection to access denied page, and not login page too?

[lightguard]

Why it isn't a problem redirecting to the login page: Because I missed it :)

Why it's a problem in the RENDER_RESPONSE phase? Because headers have already been sent to the browser for the page and we can't redirect. At least we shouldn't be able to redirect. If someone has a patch for checking to see if headers have been sent to the browser we could send the redirect if they haven't otherwise it's too late.

[blabno]

OK, if it's impossible to always restrict access before RENDERRESPONSE then I suggest that by default RestrictAtPhase is RESTOREVIEW.

[lightguard]

I think there's a JIRA for that actually.