text: How are you handling login / registration redirects?Felipe Albertao Jan 26, 2007 2:11 PM
  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
  1. Re: How are you handling login / registration redirects?Chuck Adams Jan 26, 2007 2:33 PM (in response to Felipe Albertao)
  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.
  2. Re: How are you handling login / registration redirects?Felipe Albertao Jan 26, 2007 3:56 PM (in response to Felipe Albertao)
  Here is how I am handling the redirect to the login page and then back to the original page:
  1) pages.xml:
  <page view-
  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;
  3. Re: How are you handling login / registration redirects?Christian Bauer Jan 26, 2007 4:12 PM (in response to Felipe Albertao)
  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-
  @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
  There is some more details to this overall navigation strategy, but that should get you started.
  4. Re: How are you handling login / registration redirects?Christian Bauer Jan 26, 2007 4:16 PM (in response to Felipe Albertao)
  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.
  5. Re: How are you handling login / registration redirects?Felipe Albertao Jan 26, 2007 4:16 PM (in response to Felipe Albertao)
  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
  6. Re: How are you handling login / registration redirects?Gavin King Jan 26, 2007 4:21 PM (in response to Felipe Albertao)
  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).
  7. Re: How are you handling login / registration redirects?Siarhei Dudzin Jan 26, 2007 4:31 PM (in response to Felipe Albertao)
  I use my own security filter (it's not a big webapp) which besides session checking also has settings to protect certain paths.
  8. Re: How are you handling login / registration redirects?Michael Singer Jan 26, 2007 5:18 PM (in response to Felipe Albertao)
  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:
  I think this is sufficient for my use cases...
  9. Re: How are you handling login / registration redirects?Basel Al-Mustafa Jan 26, 2007 11:36 PM (in response to Felipe Albertao)
  Does redirect.captureCurrentRequest() capture request parameters which are part of the URL as well?
  10. Re: How are you handling login / registration redirects?Christian Bauer Jan 27, 2007 4:31 AM (in response to Felipe Albertao)
  Yes, and I remove some of these possible parameters (see the Javadoc in my code) before I redirect back.
  11. Re: How are you handling login / registration redirects?Chuck Adams Feb 2, 2007 5:32 PM (in response to Felipe Albertao)
  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.
  12. Re: How are you handling login / registration redirects?Gavin King Feb 3, 2007 3:23 PM (in response to Felipe Albertao)
  @LoggedIn really needs to go from the examples.
  Agreed.