Exception for authorization attempt

[henrik.lindberg]

Hi, I get an exception when restricting access to a pages called "settings.xhtml" - this is the output:

22:52:01,046 ERROR [AbstractSeamPhaseListener] Swallowing exception thrown by page action
org.jboss.seam.security.AuthorizationException: Authorization check failed for expression [#{s:hasPermission('/settings.xhtml', 'ren
der', null)}]
at org.jboss.seam.security.Identity.checkRestriction(Identity.java:165)
at org.jboss.seam.pages.Page.enter(Page.java:185)
at org.jboss.seam.core.Pages.enterPage(Pages.java:239)
at org.jboss.seam.jsf.AbstractSeamPhaseListener.enterPage(AbstractSeamPhaseListener.java:241)
at org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:192)
at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:53)
at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:32)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:619)


And, the settings.xhtml page is rendered (as expected)
What does this mean? Do I have to have specific access rules for every page that is configured with in pages.xml?

What I would have expected would have been that access was denied since it could not find a rule that explicitly granted access.

Or maybe, I am doing something else wrong here...

[gavin.king]

Its a problem in Seam's exception handling stuff, which I am right now in the process of rewriting.

[henrik.lindberg]

ok...
I am really confused about what is going on.
I have this in my rules:

canUserRenderSettings
when
c: PermissionCheck(name == "/settings.xhtml", action == "render")
then
c.grant()
end;

Which if I have understood things correctly should always grant access for everyone that wants to render the settings.xhtml.

I still get the exception... So, I wonder what is really going on here.
For starters - is the rule correct as I have written it?

How should the case be handled when the user does not get permissions? Should I use a mechanism that redirects when there is an exception?
(Confused - as you can tell).

Regards
- henrik

[shane.bryzak]

Your rule looks right. For security exception handling you need to configure exceptions.xml to redirect to a login or error page. I've added a section to the security docs (in CVS only) that briefly describes how to do this.

[henrik.lindberg]

Thanks, looked at what was in CVS. That was helpful.
If you want to improve on the text, maybe point out that the exceptions.xml file should be under WEB-INF. (It is mentioned in the handling exceptions section thoug - that is how I figured out where to put the file.

[henrik.lindberg]

I added the exception handling as suggested, but still have the same problem.

I can see that if I am not logged in I get a NotLoggedInException, and if logged in I get an Authorization exception.

I am not redirected, there is no error page being shown, the exception is simply swallowed by AbstractSeamFaceListener (it says so in the console output).

Oh, and the page I am trying to protect is still rendered.

Could there be something else that is wrong?
When I do a build clean of the project I sometimes see that it was impossible to remove certain files. Security and drools related files most of the time. When this happens I try again (sometimes several times) until the clean build works. (I am using JBoss IDE)

[shane.bryzak]

Gavin mentioned that he would be working on the exception handling to fix this behaviour. I'm not sure why your files are locked - are they opened by any other application?

[henrik.lindberg]

The files are not opened by some other application (that I know of).
Basically the things running/using/producing these files are Eclipse (JBoss IDE), and JBoss app server.

At the moment, I can not trigger the problem on purpose - but I have a suspicion that it may have to do with having an automatic rebuild followed by a build clean and that the consequences of the first operation has not completed.

Thanks Gvin for fixing things with the exceptions. What I don't understand is how anyone can protect a page using the rules...

[shane.bryzak]

"henrik.lindberg" wrote:
What I don't understand is how anyone can protect a page using the rules...

I've updated the seamspace example in CVS to include a default page restriction - take a look at the entry for /comment.xhtml in pages.xml, and the RestrictCommentPage rule in security-rules.drl. If you browse directly to comment.xhtml, you are redirected to the registration page.

[henrik.lindberg]

Thanks, I will try that. It is different than what was said in the manual (in CVS) about putting the exceptions in exceptions.xml

[henrik.lindberg]

I tried it - does not work for me. Is it supposed to work for 1.1.5.GA, or does this depends on things only in CVS?

This is what I have done

In security.drl

canUserRenderSettings
 no-loop
 activation-group "permissions"
when
 c: PermissionCheck(name == "/settings.xhtml" || "settings", action == "render", granted == false)
then
 c.grant();
 modify(c);
end;

I.e. a very lean rule, the user only has to be logged in. I added || "settings" because I wanted to try to check permission explicetly and use "settings" as the tag - have not tried that yet though.

I added the "no-loop", and "activation-group" from the example in CVS. Also added the "modify(c)" at the end. Don't know what they are supposed to do, but I can guess.

Then in pages.xml I have the two exception declarations:

<!-- When NotLoggedInException occurs - redirect to login -->
<exception class="org.jboss.seam.security.NotLoggedInException">
 <redirect view-id="/login.xhtml">
 <faces-message>You must be a member to use this feature</faces-message>
 </redirect>
 <end-conversation/>
</exception>

<!-- When AuthorizationException occurs - redirect to error page -->
<exception class="org.jboss.seam.security.AuthorizationException">
 <redirect view-id="/security_error.xhtml">
 <faces-message>You do not have permission to do this</faces-message>
 </redirect>
 <end-conversation/>
</exception>
</pages>

(to be continued in the next post...)

[henrik.lindberg]

Then, when I actually restrict the settings page (in pages.xml) like this:

<page view-id="/settings.xhtml">
 <restrict/>
</page>

Then I get

18:00:36,890 ERROR [AbstractSeamPhaseListener] Swallowing exception thrown by page action
org.jboss.seam.security.AuthorizationException: Authorization check failed for expression [#{s:hasPermission('/settings.xhtml', 'ren
der', null)}]
 at org.jboss.seam.security.Identity.checkRestriction(Identity.java:165)
 at org.jboss.seam.pages.Page.enter(Page.java:185)
 at org.jboss.seam.core.Pages.enterPage(Pages.java:239)
 at org.jboss.seam.jsf.AbstractSeamPhaseListener.enterPage(AbstractSeamPhaseListener.java:241)
 at org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:192)
 at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:53)
 at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
 at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:32)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:46)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
 at java.lang.Thread.run(Thread.java:619)

[henrik.lindberg]

Which was the exception that I thought the declaration in pages.xml should handle.

But... maybe I am confused, and what Gavin said about "fixing the exception" actually ment that this (restricting a page as in the example) has no chance of working until the problem with this exception is fixed.

Something telling is perhaps that it says

check failed for expression [#{s:hasPermission('/settings.xhtml', 'ren
der', null)}]

with a 'null' at the end - the rule has 'granted == false'

Will test by removing that part...

[gavin.king]

Why don't you just try using current CVS, the docs in current CVS, and the example in current CVS, since we have fixed bugs and redesigned Seam exception handling.

[henrik.lindberg]

Sounds like an idea worth trying :-)