Doug Braidwood

The Container must migrate any session attributes which are serializable, but it does not have to use serialization to accomplish this.

So if your attributes are all serializable you don't have a problem, but if there are some custom bits that would normally be serialized by writeObject() and readObject() then you will need to work around this as you say with the HttpSessionActivationListener

Hi, I'm having trouble understanding how multiple <auth-constraint> elements combine.

The servlet spec says "The special case of an authorization constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded."

I set up a really simple test web.xml
<web-app> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>Member</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>Test1</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint/> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Test2</web-resource-name> <url-pattern>/index.html</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Member</role-name> </auth-constraint> </security-constraint> </web-app>

What I would have expected is that the empty <auth-constraint> on Test1 meant that no-one could see anything. In practice, if I authenticate as a member I can see index.html fine.

Am I missing something?

Kumar, I think the first thing to do is get the session timeout working on the server.
For this you need to have the <login-config><auth-method> and the <session-config><session-timeout> elements setup in web.xml
When you have this setup you should find that the first time you request a secured page you need to login.
Then you see the page you wanted, and press f5 and it refreshes without you needing to re-enter authentication details.
Then if you wait at least the timeout interval (a minute) and press f5, now the session has timed out and you are requested for login details again.

This behaviour is fairly straightforward to setup in the container. Have you got this working?

Kumar I think you are mixing up the two things. The http connection is stateless - the browser has no idea about the session objects etc. that are held on the container.
You are going along the right track when you set the timeout on the server. You need to do this, so that after one minute the session becomes invalid (I know some people have pointed out there is not a guarantee it will be in exactly one minute but in my experience it's always very close).

So on the web container side, all you need to do is set the session timeout to one minute. Try this first, wait for say 90 seconds and then refresh your browser. It should ask you to log in again, because the previous session has gone.

Once you have that working you need to look at doing something on the client side. I would suggest that involves sending back a javascript countdown. The countdown's only purpose is to wait the specified interval and then say refresh the page. Session invalidation will have been handled by the container, and the user will see the login screen again.

I'm just trying to understand the bit you are saying about being shown the logout page.

On my application you log in, a session is created and you can view your personal data. If you do not do anything, that is you do not send any further requests to the server, then after the session timeout your session will no longer be valid. In this case your personal data remains on the browser screen (the browser knows nothing about the timeout) until you click on a link or something and then a request reaches the server and the server says that the session is no longer valid.

It sounds like what you are wanting is the sort of situation like some online banks, where after a period of inactivity in the browser itself you are taken to a logout screen. If this is the case then I would have thought you need something running in the browser such as a javascript function to countdown.

Does that make sense? Invalidating the session on the web container will not affect the browser until it attempts to communicate with the container again.

As far as I'm aware setting in web.xml (in minutes) or setting it programmatically with setMaxInactiveInterval (in seconds) is no different.

What I am a bit confused about is what you are wanting to happen.
After one minute the session will be invalid, and so the isNew() test will return true, also the session attributes will have been cleared.
With your code there, if you press f5 (refresh) after less than one minute I would expect it to log "Session is old" and if you press f5 after more than one minute the session will have timed out and you will see "Session is new" (and a new session will be created).

In my application I have also used HttpSessionListener which is triggered whenever a session is created or destroyed

public class SessionTracker implements HttpSessionListener{ ... ... public void sessionCreated(HttpSessionEvent ev){ writeSessionLog(ev.getSession().getId() + " created"); } public void sessionDestroyed(HttpSessionEvent ev){ writeSessionLog("session destroyed"); } }

Thanks guys, I'm just trying to make sure that I've got the basics well understood before I add the next complexity.

At the moment the web-apps I'm building as I learn only have a couple of Controller servlets so Front Controller is probably overkill.

Once I've got SCWCD what do you think is most sensible to learn next? I thought maybe Struts and Hibernate?

David, is Front Controller not a pattern which simplifies the Controller part of MVC by reducing it from multiple Controller servlets to a single servlet?

Sorry, what I was trying to say was that it is interesting to understand the evolution of the Patterns. Seeing it in this context helps me understand why we would use them.

From my practice, I'm still at the MVC level and have not yet moved to trying to implement a Front Controller (Struts or otherwise). I think it'll be a little while before I try that.

Thanks Bear, that was an interesting article and tied a few things together in my head. Although I'm still a step or two away from trying to understand Struts properly!

Thanks Ben, I'm glad to hear I'm on the right track.

Hi there,
I'm studying for SCWCD and trying to get an understanding of the practical side. I've written a little web app, and wanted to check that the following makes sense and is good practice.

The user clicks a link and this is mapped in web.xml to a servlet.

So my Controller here is a java class extending HttpServlet.
This will do some logic and talk to other java components (the Model).
The Model returns a bean which the Controller attaches to the request and forwards to a JSP (the View).

Does that sound correct? And are Controllers typically java classes or is there a reason for implementing them as JSPs themselves?

Many thanks,
Doug

Thanks Karthik, that's exactly what I was looking for.

Hello there,

I am trying to write a little web application which will allow users to log in, and enter or retrieve data from a database.

I am using Tomcat and MySQL

It is basically working, my java components can talk to the database and I am using the JDBC realm in Tomcat for security. So I have a users and a user_roles table in the Database and Tomcat uses this to authenticate.

My question/problem is how to know which user has logged on. I would have thought this would be a session attribute but it doesn't seem to be.
Can you help?

I've been trying to get to the bottom of this and added extra tracing to the log but I'm still not reaching a solution.

What seems to be happening when you refresh on the normal .html page is that the container is not doing generating a response at all. It goes through the filter, and then when it comes to act on the response there is no response for it to act on.
Hence it throws a null pointer exception.

It's possible to code round that in the CompressrionResponseWrapper
public GZIPOutputStream getGZIPOutputStream() { if (this.servletGzipOS != null) { return this.servletGzipOS.internalGzipOS; } else { return null; } }
and in the CompressionFilter itself.
GZIPOutputStream gzos = wrappedResp.getGZIPOutputStream(); if (gzos != null){ gzos.finish(); ctx.log("finished the output stream"); } else { ctx.log("there was no output stream"); }

But I don't understand why this should be the case. And I'm not sure whether the issue that intermittently affects the .html is the same as always affects the .jsp
It's like simply no response is being generated by the Container.