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!
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.
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.
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
Logged In: YES
user_id=590231
If I understand the intent correctly, this seems like a duplicate of
#666465.
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".
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
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.