• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

how to disable the ability that last accessed page is remembered

 
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 287
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the discussion. It looks like I have to write a custom filter now.
 
Don't destroy the earth! That's where I keep all my stuff! Including this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic