how to disable the ability that last accessed page is remembered

[reubin haz]

I'm using tomcat 6 and jsf to build a web app. When a page is timed out, and the user login again, it would not go to the index page but the last accessed page. But I want it always go to the index page first. How do I disable this?

I'm not sure where exactly is this configured or implemented. Can someone give me some clue?

Thanks.

[leo donahue]

When a page is timed out, and the user login again, it would not go to the index page but the last accessed page. But I want it always go to the index page first. How do I disable this?

This isn't a JSF problem.

It sounds like your Tomcat configuration for authentication is not quite right, or your session is not really timed out. If you understand Tomcat enough to use the manager webapp, you can use that webapp to view the session information for your other webapps.

Tomcat session timeout defaults to 30 min, but you can override that in the web.xml file unique to your webapp.

[reubin haz]

I think I originally posted this thread in tomcat topic, but some moderate moved it to here...
I think it's from some tomcat mechanism but I couldn't find much documentation about this feature.

[Tim Holloway]

If you're using J2EE standard container-managed security, the container (Tomcat, Websphere, or whatever) will intercept URLs, match them up against the patterns defined in web.xml, and, if the need for elevated security is detected, it will shunt the URL aside, presenting the login process. Once login is complete, the original URL is then processed.

This is very convenient, since it means that you can make bookmarkable links to secured parts of the application, plus it eliminates one of my favourite ways of blowing the Do-It-Yourself security systems to shreds, since probably two-thirds of them make the false assumption that hackers are going to play by the rules. J2EE security knows better than that.

If bookmarkable links aren't important to you but landing on a specific home page after login is, you can add a servlet filter to the webapp.

There is no actual "login" event that you can listen for in J2EE, since if the site is set up with Single Singon, the user could have done their actual login 25 minutes earlier to an entirely different application, possibly even running in an entirely different server (which might not even have been a Java server). Or in the most extreme case, security might have been done when the user logged into their computer. So that can make things a little sticky.

But, allowing for that, there's a simple way to tell when a user has logged in, even if it's a bit indirect and after the fact.

If the request getUser and getUserPrincipal functions return null, the user is not logged in, even though, he, she, it, or whatever may have an HTTPSession object. The detection of login is as simple as detecting the transition from null to not-null. Obviously, you have to have someplace to store the prior state so you can compare, and normally that would be an HttpSession attribute.

So, if the user ID is not null, but the cached used ID for the previous request WAS null, you've caught a login. Obviously, that includes the situation where there was no previous session, so once login is detected, discard the incoming URL and forward to your home page.

It takes roughly 5-10 lines of code. If the user was logged out - either explicitly due or due to timeout, you end up with no previously-cached user ID, since the HttpSession was destroyed and that addresses your specific inquiry.

[reubin haz]

Thanks Tim for the light up.

I had some thought about my tomcat configuration. The most possible scenario might come from this: my tomcat web.xml has the default 30 mins time out. But my project web.xml has 20 mins. So would this leave 10 mins gap that the project is timed out but tomcat still remember last accessed page and something else?

I had a test between 20 mins and 30 mins to click some page, but once I login again, I thought tomcat would redirect to my last accessed page but it goes to the welcome page defined in my project web.xml.

This happens rarely and I cannot reproduce this bug the client reported, which makes me hard to know where exactly to fix it and test it.

[Tim Holloway]

As far as I know, the tomcat web.xml timeout is simply the server's default value if you don't override it with an explict value in web.xml. So if you provide a timeout in web.xml (and you usually should!), then Tomcat should neither know nor care what the server default value was within that particular webapp.

Meaning that if you're having problems, I don't think they're related to a difference between the two timeout settings.

[leo donahue]

So would this leave 10 mins gap

I'm leaning towards no on this.

Unless you have code that extends or manipulates the session timeout (HttpSession), defining it in web.xml of your web app is where it will expire. If you didn't define it there, then it would use the session value in /conf/web.xml


Tim,

According to the servlet spec for 2.5, SRV.9.13, if your web app only serves static content or JSP, web.xml is not required in your webapp.

[Tim Holloway]

The operative word there is required. As is the general trend, webapps are moving towards xml-free configuration. I consider this a mixed blessing, since it's more stuff to keep up when you use an XML config file, but conversely, it puts the config information in a single visible place.

I'm less concerned about whether one uses a web.xml or not than I am about whether you know what your timeout is or you depend on an outside source. I prefer stating it explicitly, although certainly there are cases where controlling it per-server instead of per-app are good. Such as enforcing a corporate site-wide standard.

I should note that web.xml was created as much as a deployment descriptor as anything else, and under the JSR-88 remote deployer specification it made up half of everything needed to deploy a webapp. It defined the container-independent properties and a separate data stream (which didn't actually have to be XML, but usually was) provided the container-specific properties. So it's not considered illegal to unpack a WAR, alter selected web.xml settings and deploy the WAR with alternative settings. In a few cases, in fact, such as role aliasing, it might even be essential sometimes.

Regardless, I think we're in agreeement on one key issue: if there is a web.xml and if it contains a timeout, that timeout is the one and only timeout that applies to that particular WAR.

[leo donahue]

Regardless, I think we're in agreeement on one key issue: if there is a web.xml and if it contains a timeout, that timeout is the one and only timeout that applies to that particular WAR.

Yes, in agreement.

I was only stating the other information as an fyi.

As far as the "login again" issue Reubin has, it sounds to me like a roll-your-own design problem.

[reubin haz]

thanks for the discussion. It looks like I have to write a custom filter now.