Appear I have different issue, because on index.jsp I have
${pageContext.request.remoteUser} that is returning a valid username,
and when accessing a secure area, username/password is not asked again
(until a session reset - see "Session Reset" thread!!!).
Currently, I'm suffering the two issues... session never ending or
session being reset by an IOException!
Thanks,
Richter
Jan Luehe escreveu:
>
>
> Edson Carlos Ericksson Richter wrote On 06/21/06 09:06,:
>
>> I have a page for "logout". The code is:
>>
>> <%
>> request.getSession().invalidate();
>> System.err.println((new
>> com.sun.appserv.security.ProgrammaticLogin()).logout(request,
>> response, true));
>>
>> response.sendRedirect(request.getContextPath()+"?_br_lastMessage=Saída
>> do sistema com sucesso!");
>> %>
>>
>> I expect session is invalidated, the user is logout, and redirected
>> to index page.
>> Sometimes, session stay existing, user is not logged out (besides
>> "true" appear on log), and authentication is not asked again.
>>
>> Occur in Glassfish (standalone, started from NB) and SunApp Server 9
>> (running as service).
>> Problem is shown randomly.
>
> There is a known issue right now which causes the session ID of an
> invalidated session to be returned in the Set-Cookie response
> header. This is because the session ID is added to the response
> Set-Cookie response header at the time it is created from the request,
> and is not removed from the response should it later be invalidated.
>
> This is not a real problem, because any subsequent request that
> carries the ID of the invalidated session in its Cookie request header
> will not be able to resume the invalidated session, because the
> session manager will not return any session object for it. The lookup
> of the session ID is redundant, though, since it is already known in
> advance that the session ID is invalid.
>
> Removing an invalidated session ID from the response (or delaying
> the addition of the Set-Cookie response header to the time when the
> response is finalized, and adding it only if a session exists and is
> still
> valid) would therefore improve the performance of a subsequent request,
> because it would avoid the redundant session ID lookup.
>
> Notice that URL rewriting is not suffering from this issue, i.e., if a
> session has been invalidated, its session ID won't be appended to the
> URL.
>
> (On a sidenote, the advice is to always pass a URL through
> encodeRedirectURL() when preparing it as a parameter to the
> HttpServletResponse.sendRedirect() method. You may want to consider
> this for your code.)
>
> In any case, a session that has been invalidated will never be
> resumed. In case you have SSO enabled, the invalidated session will
> also have been deregistered from SSO.
>
> Can you submit a WAR that would allow us to reproduce the issue
> you've run into?
>
> Thanks,
>
> Jan
>
>>
>> Richter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>
>