Menu

#12 Application-specific processing on authentication

open
nobody
9
2003-10-26
2003-01-17
No

It would be nice to add an (true|false) attribute to
the configuration file, perhaps to
the /securityfilter-config/login-config/form-
login-config element, to allow for the filter to
always forward to the default page after successful
authentication. This would allow the application to
do some further processing on its own with regard
to the login process.

On the code side, it's a simple change to
SecurityFilter.getContinueToURL
(HttpServletRequest):

E.g. --

if (savedURL != null && alwaysForwardToDefault
== false) {
return savedURL;
} else {
return request.getContextPath() + defaultPage;
}

Sorry, I'm not familiar with CVS or I'd send a diff for
that code and the piece in SecurityConfig for the
digester load, which also needs tweaking to
accommodate the extra attribute. I've already
hacked this for my application. If you'd like the
altered files, send me a note at kalitai AT yahoo
DOT com. Cheers!

Discussion

  • Daya Sharma

    Daya Sharma - 2003-01-18

    Logged In: YES
    user_id=249161

    why would a user like to forward to a default page after the
    user has successfully logged in. The very fact that the user
    was challenged for the credentials proves that the user was
    attempting to access a protected resource, hence the user
    should be forwared to that protected resource after successful
    authentication.

    Imagine every time the user is directed to a constant default
    page every time he/she accesses any protected resource and
    supplies the credentials. That would be confusing the user
    IMHO.

     
  • Darren Spurgeon

    Darren Spurgeon - 2003-01-20

    Logged In: YES
    user_id=311499

    In reply to dayash's comments...

    You misunderstand my point. The challenge is initiated upon
    the *initial* hit to the resource. After successful login, the
    credentials are recognized throughout the life of the session.
    Thus, the redirect is only applicable on the login. Each
    subsequent hit within that same active session would not
    invoke a redirect. Make sense?

    As I mentioned, the code change is minimal, I am using it
    successfully, and there is *only one* redirect after login as a
    result.

     
  • Max Cooper

    Max Cooper - 2003-03-06

    Logged In: YES
    user_id=590231

    Forcing the user to the default page under all circumstances
    would break the "just in time" login behavior. When a user clicks
    a link to some protected resource, they should be sent throgh the
    login process and then end up where they originally wanted to
    go. If we force them to the default page after logging in, they
    might be a bit bewildered. This kind of thing is especially
    important if people email links to protected pages to each other,
    etc.

    If the goal is to allow some application-specific processing upon
    successful login, perhaps we could simply support a server-side
    forward to some resource (servlet, JSP, whatever) for that as
    part of the j_security_check submit. We could wrap the response
    so that anything the processing resource writes to the response
    would be ignored, and the server could respond with the redirect
    to the protected page after the processing completes.

    We could also specify some API that would allow app developers
    the opportunity to implement and specify a class that would have
    a method called (with the Request, etc.) when a user
    authenticates. We inherit the weight of maintaining the interface,
    which is a downside to this approach, but at least it would be
    clear that you can't write stuff to the response this way. I think I
    am leaning toward the forward idea, above, as it seems more
    simple.

    -Max

     
  • Max Cooper

    Max Cooper - 2003-03-06

    Logged In: YES
    user_id=590231

    If I understand the intent correctly, this seems like a duplicate of
    #666465.

     
  • Darren Spurgeon

    Darren Spurgeon - 2003-03-07

    Logged In: YES
    user_id=311499

    Yes, I agree that #666465 is very similar to, if not more inline
    with, what I'm thinking here. The intent of my request is to
    load information into the session at logon. If that can be
    done and still forward to the originally requested resource, all
    the better. However, I'm not experienced enough to assess
    which method is (or even if both are) more secure or follows
    more closely the J2EE "standard".

     
  • Max Cooper

    Max Cooper - 2003-04-05

    Logged In: YES
    user_id=590231

    The J2EE standard that SecurityFilter closely follows (with a few
    exceptions) is the Servlet Spec Security section.

    Adding some kind of "processing upon authentication event" is
    not supported by the spec. There are ways to implement this kind
    of thing on top of container-managed security (CMS) and they
    would also work with any release of SecurityFilter. If you want
    portability between CMS and SecurityFilter, a standard solution
    is the way to go.

    Here are a few such solutions:

    1. Write a filter and a session listener. Keep track of what
    request.getUserPrinciple() returned on the last time through the
    Filter for each Session. If the value changes (was null, now it
    isn't, etc.) do your processing. Use a session listener or a timed
    cache expiration to make sure that your Map of session_id
    values to what_getUserPrincipal()_returned_last values does not
    grow continuously as the application runs. A simpler solution
    might be to just put the what_getUserPrincipal()_returned_last
    value in the user's session itself, so you don't have to maintain
    the Map. I have considered creating a new project for software
    along these lines, but SecurityFilter and my real job have been
    keeping me too busy to work on it.

    2. Use a custom method to access the session information, so
    that it can be created on the fly if it doesn't exist yet. Here's a
    code example:

    public class UserProfile implements Serializable {
    public static final String SESSION_KEY
    = "my.package.UserProfile";

    public static UserProfile getUserProfile(HttpServletRequest
    request) {
    HttpSession session = request.getSession();
    synchronized (session) { // synchronize to be sure that you
    never create two profile instances for the same session
    UserProfile profile = session.getAttribute(SESSION_KEY);
    if (profile == null) {
    profile = new UserProfile();
    session.setAttribute(SESSION_KEY, profile);
    }
    }
    return profile;
    }
    // add whatever stuff you want -- probably need to load/save in
    db for this to be useful
    private String favoriteColor;
    public String getFavoriteColor() {
    return favoriteColor;
    }
    public void setFavoriteColor(String color) {
    favoriteColor = color;
    }
    }

    Then, if you wanted to access the currect user's current profile
    and print their favorite color out, you could do this:

    UserProfile profile = UserProfile.getUserProfile(request);
    System.out.println("Your favorite color is " +
    profile.getFavoriteColor());

    3. Perhaps some combination of the two. Make a class to do the
    on the fly creation (perhaps only if the user in indeed logged in)
    and then add a filter to just ensure the object is in the session for
    each request, so that it can be reached with a simple call to
    session.getAttribute(UserProfile.SESSION_KEY).

    Loading some stuff into the session or doing some other
    application-specific processing is so common a request,
    however, that perhaps some explicit support for it could be added
    to SecurityFilter. But it won't happen right away, and using it
    would couple your app to SecurityFilter, so it might be best to
    find another way to do what you need to do, at least in the mean
    time and probably generally as well. There are several ways to
    achieve this functionality without explicit support from CMS or
    SecurityFilter.

    -Max

     
  • Max Cooper

    Max Cooper - 2003-04-05

    Logged In: YES
    user_id=590231

    I closed the original request that was more general than this one
    but was essentially a duplicate. I changed the name of this
    request to indicate the general nature of the requested
    functionality. I also copied the information from that request here:

    It is a common request to support application-specific
    processing upon successful authentication. This would
    support loading a user profile into the session, etc. The
    Servlet spec does not support such processing.

    One possible implementation is to allow the application to
    specify a resource (Struts Action, servlet, JSP, whatever)
    that should be executed upon successful authentication.
    The filter could forward the request to the resource when a
    login submit request succeeds. A ResponseWrapper could
    be used to prevent the resource from making any changes
    to the response (by disabling the methods on the response
    that allow it to be modified -- calls to these methods will be
    ignored). After the forward, the filter could do its normal job
    of sending a redirect to the protected resource that initiated
    the login sequence.

     
  • Max Cooper

    Max Cooper - 2003-04-05
    • summary: Add attribute to always forward to default page --> Application-specific processing on authentication
     
  • Max Cooper

    Max Cooper - 2003-10-26
    • priority: 5 --> 9
     

Log in to post a comment.