How are you handling login / registration redirects?

[felipevaa]

Hello!

I'm just curious to know what others developers are doing in general to implement login / registration redirects, and what's working or not working for you: JAAS-Based? Tomcat auth? @LoggedIn?

I've been using pages.xml to "protect" pages and directories behind a login action, and although this is not a clean solution (and perhaps not very secure), It's working well for me. I was just wondering what other developers are doing...

Thanks!

Felipe

[cja987]

I've been using @LoggedIn. It's a hack, but if it's good enough for the booking example, it's good enough for my simple CRUD app. I tweaked it a bit to return a "nologin" result in order to redirect to the login page when users attempt an action that requires a login.

I'd love to know how to send them back to the original page, since just using the http referer isn't really good enough, but I used a javascript history hack (a "go back" link) that also works (thanks in no small part to JSF/Seam's mojo). I'm okay with making my users use that approach, since it's an internal app with potentially a couple dozen users total, all quite used to even clunkier interfaces.

I hope to migrate to a "real" security system eventually, since I'll want to eventually support user roles. Hopefully there will be a simple example of it I can use by then. The seamspace example has a security mechanism, but it looks awfully complex.

[felipevaa]

Here is how I am handling the redirect to the login page and then back to the original page:

1) pages.xml:

 <page view-id="/directory/*" action="#{loginAction.checkLogin}"/>

2) loginAction.checkLogin():

if( user is already logged in )
{
 return null; // Do nothing (i. e.: proceed with pages.xml chain)
}
else
{
 // Or else, store current view-id on session and redir user to login page
 Contexts.getSessionContext().set("viewIdAfterLogin",
 FacesContext.getCurrentInstance().getViewRoot().getViewId());
 return "/login.xhtml";
}

3) loginAction.login():

... // after user and password was validated

String viewIdToRedirect =
 (String)Contexts.getSessionContext().get("viewIdAfterLogin");
Contexts.getSessionContext().set("viewIdAfterLogin", null);
return viewIdToRedirect;

[christian.bauer]

I use this (for similar functionality), which is better because it is conversation scoped (app works in several windows):

On every page I can get "back" to, I store it in a conversation scoped component with a page action in pages.xml:

 <page view-id="/docDisplay.xhtml" action="#{documentBrowser.prepare()}">

@Name("documentBrowser")
public class DocumentBrowser {

 @In
 protected org.jboss.seam.core.Redirect redirect;

 public String prepare() {

 // Store the view-id that called this method (as a page action) for return (exit of a later conversation)
 redirect.captureCurrentRequest();
 }

 /**
 * Executes a redirect to the last view-id that was prepare()ed.
 * <p>
 * Usually called after ending a conversation. Assumes that the caller of the method does not want to propagate
 * the current (ended) conversation across that redirect. Also removes any stored <tt>actionOutcome</tt>,
 * <tt>actionMethod</tt> or <tt>cid</tt> request parameter before redirecting, we don't want to redirect to
 * a prepare()ed page that was in a long-running conversation (temporary doesn't matter) or that was last
 * called with an action (that action would probably send us straight back into the conversation we are trying
 * to redirect out of).
 */
 public void redirectToLastBrowsedPage() {

 // We don't want to redirect to an action, so if the last browsed page was called with an action, remove it
 redirect.getParameters().remove("actionOutcome");
 redirect.getParameters().remove("actionMethod");

 // If the last browsed page had a conversation identifier (we assume of a temporary conversation), remove it
 redirect.getParameters().remove("cid");

 // We also don't want to redirect the long-running conversation, the caller has ended it already
 redirect.setConversationPropagationEnabled(false);

 redirect.execute();
 }

}

And I can then later exit a conversation like this and redirect to the last "prepared" page:

 <s:button id="exit" value="Exit Editor" styleClass="button" action="#{documentBrowser.redirectToLastBrowsedPage()}"
 propagation="end"/>

There is some more details to this overall navigation strategy, but that should get you started.

[christian.bauer]

Note that "documentBrowser" is an Event scoped component. The org.jboss.seam.core.Redirect is Conversation scoped. So when I enter an Edit screen (or Login screen), I promote the temporary conversation, which contains the Redirect component, to a long-running conversation. This is the conversation I then later end and exit, and I still have the same Redirect instance to do that.

[felipevaa]

This is great, because I was experiencing some issues with conversations in my redirect method. I'll definitely use your approach from now on.

Do you know if the new security support scheduled for Seam 1.5 will include anything related to this redirect issue?

Felipe

[gavin.king]

Do you know if the new security support scheduled for Seam 1.5 will include anything related to this redirect issue?

I would like to include some functionality like this, but it might not be in the first release (next week).

[svadu]

I use my own security filter (it's not a big webapp) which besides session checking also has settings to protect certain paths.

[mikepkp17]

I am also thinking about a solution where I can protect a directory or a page.

The solution should be able to switch between http and https protocol and I actually found this:

http://tuckey.org/urlrewrite/

I think this is sufficient for my use cases...

[basel]

Does redirect.captureCurrentRequest() capture request parameters which are part of the URL as well?

[christian.bauer]

Yes, and I remove some of these possible parameters (see the Javadoc in my code) before I redirect back.

[cja987]

Okay, subtract me from the people using @LoggedIn -- it's simply evil, and it seems to interfere with bijection and @Create methods. Until I devote some time to reading up on Seam Security, I've literally hardcoded the login check into every method that would use it (which is actually not many places thankfully).

@LoggedIn really needs to go from the examples.

[gavin.king]

@LoggedIn really needs to go from the examples.

Agreed.