How to make <restrict> work without an action?

[bobthule]

The restrict element in pages.xml is not causing a security exception when users navigate to a page (ie: clicks a link to http://localhost/test/admin/admin.seam).  The exception is only being thrown when a user calls an action.  To work around the problem, I added a default no-opp page action.  This works, but it doesn't seem like it should be necessary. 

Is this expected behavior, or does Seam have a bug, or is there some setting that I have wrong? 

My work-around code is below.  I don't think I should have to have the action element in the pages.xml.

pages.xml

    <page view-id="/admin/*" login-required="true">
          <restrict>#{s:hasRole('Admin')}</restrict>
          <action execute="#{app.noOp}" on-postback="false"/>
    </page>

App.java

Name("app")
public class App{
     public void noOp() { }
}

[gonorrhea]

I am using the following successfully in my app:

<page view-id="/AssignToStorage.xhtml">
         <restrict>#{s:hasRole('manager') || s:hasRole('admin')}</restrict>
    </page>

So that means you don't need to specify an action for Seam to execute...

Have you tried this?  Page-level security in Seam using s:hasRole was one of the easier and nicer things I liked about this fwk when I started using Seam 1.2.x...

You need to make sure that the Seam identity instance is populated with the current session's user's role(s) during authentication/authorization process...

ex:

if (theUser.isMemberOf(sid)) {
                         log.debug("(TokenGroup) Found match for: "
                                   + secRole.getSecurityRoleName());
                         identity.addRole(secRole.getSecurityRoleName());
                         continue;
                    }

[bobthule]

Hi Arbi,

If you login to you app with a user who does not have a 'manager' or 'admin' role and then try to go directly to http://yourserver.net/AssignToStorage.seam, do you get a security exception? 

In my app, if I were to do the same thing, it would render the page just fine!  The only time it fails is if I try to call an action from that page.  For example, if I click a button with an action "#{whateverAction.doThis}".  Stranger yet, when it fails, it still doesn't cause an exception-- it simply does not run the action before re-rendering the page.  If I login with a user who passes the restriction, it renders the page (as expected) and the action runs and the page re-renders when the button is clicked (as expected).  So the settings in the restrict element are being used, just not fully correctly.

If I add in the no-op page action, the exception occurs as expected-- but I don't think I am supposed to have to add that no-op page action, so I am wondering what is going on!

I am using Seam 2.1.1.GA with Facelets 1.1.15.B1 and JSF 1.2_12.  Maybe it has something to do with the newer Facelets or JSF.  I can't remember why our team had to move to these newer libs, but it was because of some issues we were having.

[gonorrhea]

We are using NTLM (silent) authentication with IE browser via JCIFS library in our Authenticator component.

So basically anybody already logged into our network will be authenticated for any of our Seam apps.

Then the authorization routine will not add any roles for that user to the Seam identity instance if they are not a member of any security groups in Active Directory (although the roles/groups can be stored in a DB with Seam 2.1 Identity Management API, specifically JpaIdentityStore).

So the answer to your question (without trying this myself :), is that the user will be forwarded to the error.xhtml with verbage like you do not have permission to view this page.  You need to add something like the following to your pages.xml:

<exception class="org.jboss.seam.security.AuthorizationException">
        <redirect view-id="/error.xhtml">
            <message>You don't have permission to do this</message>
        </redirect>
    </exception>

[bobthule]

Thanks Arbi, it's fixed based on your exception section.  I knew I could add that section, but I never bothered because I wasn't seeing any exceptions in the log and I wasn't being directed to debug page. 

But, apparently Seam must be swallowing the AuthorizationExceptions if pages.xml is not setup to catch and redirect on them specifically.