On 22/09/2011 13:56, Shanti Suresh wrote:
> Hi Martin,
>
> You will have to expire/invalidate the session in the code upon user logout.
> This way when the cookie comes in, there is no corresponding session-ID and
> the system will create a new session. Are you doing that already? Does that
> help?
>
> -Shanti
>
> On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:
>
> Martin,
>
> On 9/18/2011 11:05 AM, Martin O'Shea wrote:
>>>> I have a situation where I'm using Tomcat 6.0.26 but the logging in
>>>> / out of the application is not authenticated via Tomcat's:
>>>>
>>>> action='<%= response.encodeURL("j_security_check") %>' >
>>>>
>>>> method.
>
> You mean to say that you are using your own authentication mechanism,
> right?I think we should clarify what is really happening. The code sample above implies authentication is occurring. If authentication is successful, the userid is then stored in a cookie. The OP states that cookie data is used to display personalised lists of information. Martin: how is the data being stored in a cookie - do you mean a custom cookie, or are you referring to the cookie generated for the session? Can you show a code sample of how the userid is retrieved from the cookie? p >>>> The current system allows cookies to store userids which are used >>>> to show recent lists on the homepage of the application. So for a >>>> session, a user's userid can be read from the cookie and used to >>>> retrieve their details from the database and store them in the >>>> session, and render the hompage with its personalised recent list. > > So, any remote user can provide a forged cookie to read anyone's > "recent list" if they want? You might want to encrypt those cookies. > >>>> The user's id can also then be placed in the login username box >>>> with the password stored in the session. > > So, you use an untrusted user id coming from a remote cookie to > populate the user's username and password on a login page? Sounds like > that's a problem. > >>>> But, in a single browser session, if the first user logs out, and >>>> another user logs in, the cookie is re-written with the new user's >>>> userid. But, because this is all in one browser session, use of the >>>> browser's back button allows the new user to access the profile >>>> details of the first user if the first user visited the page before >>>> logging off. > > So, what you are saying is that the design of the web browser allows a > second user to observe what the first user did by looking at the > history and/or cache? There's not a lot you can do about that. You can > send "no-cache" response headers to the browser, etc. but there's > always a chance that the browser doesn't respect them, etc. and the > history can be viewed. > > I'm not sure there's a way around that. Even if you use javascript to > kill the window/tab, many browsers have a "re-open closed window/tab" > that will resurrect the window/tab with the history in-tact, so you > haven't bought anything there. > > I guess this is why you should be careful what you do from as public > terminal, eh? > >>>> No secure data is held in the system. > > That's good, given the shaky security you've described here. > >>>> Can anyone suggest a way to change this? I am no expert on session >>>> management. > > It's the browser that is the problem, not your session management. I > think you need to instruct your users to completely exit the browser > after they use your site if they value their privacy. > > -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> !DSPAM:4e78cb6c11371347337680! >> >> >> > > -- > Shanti Suresh > App Systems Analyst Lead > Web Services, LSA Development > University of Michigan > Office: 734-763-4807 > sha...@umich.edu > http://lsa.umich.edu/cms > > > > > >
signature.asc
Description: OpenPGP digital signature
