This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Kind of LoginListener Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Kind of LoginListener" Watch "Kind of LoginListener" New topic
Author

Kind of LoginListener

Xavi Sanchez
Greenhorn

Joined: Mar 11, 2008
Posts: 15
Hi!

I got SCJP 5 with 90% on december and now I�m preparing to take SCWCD 5 soon. As I prepare, I try to think how to apply what I�m learning to an application of my company that we will probably soon refactor, and there�s something for which I haven�t found a satisfactory answer. I�ll try to be brief, so if you want further clarifications please just let me know.

1.- All the resources are restricted, I mean the user always has to be logged in to do anything.
2.- There�s information about the user that I always want to keep in session, as it will be used very often, like look & feel preferences.
3.- At the moment this info is loaded in our own login method.

If we change to declarative container managed security (auth-method=FORM, although I think it doesn�t matter), as we can�t control the login method, is there any way we could achieve the same thing? I mean, loading the info when the user logs in, so that we don�t have to check if the info is already there or not throught the rest of requests. It would be like a LoginListener.

Thanks a lot in advance!
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

There's a few ways to handle this.

1) Have a single smart object in session that contains all session data. When the user asks for a value that it didn't yet load, it knows to hit the backend and load the needed data before passing it along. Not many people use this strategy but it can work wonders.
2) Make a listener that is mapped to the entire secure area. The benefit here is that you don't have to change much code. On the downside the filter gets run on every single request.
3) Make sure a session doesn't get activated until login. This includes putting a page directive with session="false" in the login and other unsecured JSPs. Then, in theory, you should be able to implement an HttpSessionListener to run when the session is created. Assuming the session gets created after login (which might be impossible - I've never tried it).
4) I'm sure there's other solutions. Any ideas, folks?


A good workman is known by his tools.
Xavi Sanchez
Greenhorn

Joined: Mar 11, 2008
Posts: 15
Hi Marc.

Thanks for your answer and, by the way, thanks for tour patterns notes! Just a few comments:

1)Althought I don't like it very much, it's the best soluton in performance right now.
2)I had thought of an Intercepting Filter, but as you comment every request is verified, and I'd like to avoid that.
3)I really don't see this one. Even assuming what you say, how would I get the user in the HttpSessionListener?

There isn't really another way? Any idea if future specs will allow something like this?

Thanks again.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Xavi Sanchez:
3)I really don't see this one. Even assuming what you say, how would I get the user in the HttpSessionListener?

Good point. I was expecting that the corresponding request would be retrievable through the event object. Unfortunately, I'm wrong here because the event object only holds the session object. I guess forget about my number 3.

I think the filter might be the most popular solution. I agree that it doesn't seem right that every single incoming request needs to hit it. The performance overhead is incredibly minor but still it's the principle of it as much as anything.

I think your idea of a login listener method makes a lot of sense. There's nothing I know of like that in the current spec and I haven't heard of one to get added in the near future.
Xavi Sanchez
Greenhorn

Joined: Mar 11, 2008
Posts: 15
I�ve been collecting suggestions and invetigating on other forums here on JavaRanch and here�s what I�ve got by the moment:

1)Work fellow suggested using JAAS:
a.I think it�s complicating it too much for what I want to do
b.I think I won�t have access to the session during the login process, so anyone knows if, after the authentication, request.getUserPrincipal() will return my own full JAAS principal object or another implementation with just the user login? Because java doc says �Returns a java.security.Principal object containing the name of the current authenticated user�. Anyway I suppose that depends on the vendor, so I wouldn�t like to loose platform neutrality either.
c.Should I open post with this on security forum?

2)Use own login method and authenticate programmatically on container:
a.I think there isn�t a standard way of doing, so if it can be done and how depends on the vendor. Loosing platform neutrality again.

Worst of all is that another work fellow keeps picking on me because this can be done in . NET, and do you know how? with a LoginEvent (I don�t know if it�s true, but I suppose so)

So what the hell I have to do to get my LoginListener brilliant idea included in the next spec? Or shall I move to .Net ?

Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Xavi Sanchez:
Worst of all is that another work fellow keeps picking on me because this can be done in . NET, and do you know how? with a LoginEvent (I don�t know if it�s true, but I suppose so)

.NET has done a good job with stuff like this. There's been more than once I've had to say: "Oh... that makes a lot of sense. Why the heck don't we have this in Java EE!"
Xavi Sanchez
Greenhorn

Joined: Mar 11, 2008
Posts: 15
Hi.

I've done the HFSJ mock exam and I am very surprised about 2 questions:

Q53: What type of listener could be used to log the user name of a user at the time that she logs into a system?

A. HttpSessionListener
B. ServletContextListener
C. HttpSessionAttributeListener
D. ServletContextAttributeListener

Answer: C

Q31: How would you write the JSP standard action code to import a JSP segment that generates a menu that is parametrized by the user's role?

A. <jsp:include page="user-menu.jsp">
<jsp:param name="userRole" value="${user.role}" />
</jsp:include>
B. Idem with jsp:import
C. Idem with jsp:parameter
D. Idem with jsp:import and jsp:parameter
E. This CANNOT be done using a JSP atandard action

Answer: A

Can anyone explain?
 
Consider Paul's rocket mass heater.
 
subject: Kind of LoginListener
 
Similar Threads
Login SSO mixing
RMI implementation
JAAS and Tomcat
New to WebSphere and need help
Error Handling