page specific login-required=

[codelion]

Have a wildcard login-required="true".

Have a page specific login-required="false".

It appears not to be effective.

Why do I need it? Because I want different login depending on which part of the site. One part is for mobile devices. Very different. So in the login-view-id I point to where in a .page.xml it calls an action that based upon redirect.getViewId() decides where to go for actual login page. That actual login page then triggers the login-required, and isn't "exempt" because it doesn't match the login-view-id. It worked when I used <render... to get to the actual page, but then I needed on the actual page another action executed, and <render... doesn't go there, so I have to use <redirect... and that triggers the login-required.

I guess even if I'd dig for the code that makes login-required="false" not override there might be objection to making it override, is there?

Alternate solutions?

[codelion]

I've missed that already once, can you please explain where the inheritance of login-required happens?

I can't see it in package core class Pages or in package pages class Page.

I am looking at where there are references to (uses of) Page methods isLoginRequired and setLoginRequired.

I am missing something similar to the search in Pages method getNoConversationViewId(String viewId) or anything that hints at inheritance.

[gavin.king]

Pages.enterPage()

[codelion]

Found it in Pages method enterPage in the for loop over getPageStack.

One could argue whether a specific setting for a page should be allowed to override a wildcard setting.

Admittedly, the way it is many people will feel safer.

[codelion]

Gavin's answer wasn't on my screen. Sorry. Left desk, came back and finished typing ten minutes later...

Thanks for pointer!

Still trying to figure my original problem to allow login to go across multiple pages without going into a loop on then violating login-required="true".

[codelion]

Consequentially registration of new users for which obviously login-required="true" doesn't work.

So as it is that prevents us from having a

<page view-id="*" scheme="http" login-required="true">

because we cannot have a subsection of the site then that allows registration.

I'd rather do a search for login-required to make sure there is no inappropriate login-required="false" than having to remember to put in a new login-required="true" for each new directory.

Maybe we can even figure an Ant task that fails if a new login-required appears, or something like that, if we want to be secure.

But I do want to open up individual pages for login-required="false".

Any thoughts?

[codelion]

How about only allowing login-required="false" to override if set specifically for one page?

That means keep it as it is now, unless an explicitely set login-required="false" for a specific page, not a wildcard, is in effect?

Then even in a site that requires login everywhere else one could still have user registration or teaser pages.

[codelion]

Here is a beginning patch, is this something I should continue or drop?

### Eclipse Workspace Patch 1.0
#P jboss-seam
Index: src/main/org/jboss/seam/core/Pages.java
===================================================================
RCS file: /cvsroot/jboss/jboss-seam/src/main/org/jboss/seam/core/Pages.java,v
retrieving revision 1.102
diff -u -r1.102 Pages.java
--- src/main/org/jboss/seam/core/Pages.java 25 Feb 2007 22:38:21 -0000 1.102
+++ src/main/org/jboss/seam/core/Pages.java 8 Mar 2007 02:01:14 -0000
@@ -22,6 +22,7 @@
 import javax.faces.context.FacesContext;
 import javax.servlet.http.HttpServletRequest;

+import org.dom4j.Attribute;
 import org.dom4j.DocumentException;
 import org.dom4j.Element;
 import org.jboss.seam.Component;
@@ -860,7 +861,11 @@

 page.setNoConversationViewId( element.attributeValue("no-conversation-view-id") );
 page.setConversationRequired( "true".equals( element.attributeValue("conversation-required") ) );
- page.setLoginRequired( "true".equals( element.attributeValue("login-required") ) );
+ Attribute loginRequiredAttribute = element.attribute("login-required");
+ if (loginRequiredAttribute != null)
+ {
+ page.setLoginRequired( "true".equals( loginRequiredAttribute.getValue() ) );
+ }
 page.setScheme( element.attributeValue("scheme") );

 Action action = parseAction(element, "action");
Index: src/main/org/jboss/seam/pages/Page.java
===================================================================
RCS file: /cvsroot/jboss/jboss-seam/src/main/org/jboss/seam/pages/Page.java,v
retrieving revision 1.14
diff -u -r1.14 Page.java
--- src/main/org/jboss/seam/pages/Page.java 22 Feb 2007 15:12:22 -0000 1.14
+++ src/main/org/jboss/seam/pages/Page.java 8 Mar 2007 02:01:14 -0000
@@ -16,6 +16,7 @@
 public final class Page
 {
 private final String viewId;
+ private final boolean specificViewId;
 private String description;
 private Integer timeout;
 private String noConversationViewId;
@@ -28,6 +29,7 @@
 private Navigation defaultNavigation;
 private boolean conversationRequired;
 private boolean loginRequired;
+ private boolean loginRequiredExplicitelySet;
 private ConversationControl conversationControl = new ConversationControl();
 private TaskControl taskControl = new TaskControl();
 private ProcessControl processControl = new ProcessControl();
@@ -54,11 +56,14 @@
 this.viewId = viewId;
 if (viewId!=null)
 {
+ specificViewId = !viewId.endsWith("*");
 int loc = viewId.lastIndexOf('.');
 if ( loc>0 && viewId.startsWith("/") )
 {
 this.setResourceBundleName( viewId.substring(1, loc) );
 }
+ } else {
+ specificViewId = false;
 }
 }

@@ -268,6 +273,7 @@
 public void setLoginRequired(boolean loginRequired)
 {
 this.loginRequired = loginRequired;
+ loginRequiredExplicitelySet = true;
 }

 public String getScheme()

[baz]

I do not have understand why you can not have your pages ordered in this way:

app
 login_required
 pagea
 pageb
 nologin
 pagea
 pageb

Than you can have one rule

<page view-id="login_required/*" scheme="http" login-required="true">

[codelion]

Can I help along JBSEAM-1009 by writing regression tests for it? Please point me to relevant files in Seam source that test security so I can "imitate".

My current application would be a pain to secure without it, and I'm planning on writing another app. I am interested in having 1009 in an official release to reduce client resistance (to using a modified Seam).

Are there changes in security planned for Seam 1.3 that would replace 1009?

IMHO the increasingly tighter security from broad to specific wildcard was a interesting start (I mean thanks for putting it in), but is rather "possible" not "desirable". Problem is people getting used to it will prevent you from making more practical security (1009) the default.