We have an SSL protected IIS 5/W2K SP4 server using basic auth, ASP, and IE
6 SP1 clients.

We're trying to force the user to re-authenticate after a 20 minute session
timeout so we can re-populate the session vars.  However, the user is still
authenticated and does not recieve a logon prompt, even though the session
vars appear empty.

Anonymous access is disabled and NTFS perms are set on all folders.  Pragma
no-cache is set and response.expires = -1.  HTTP keep-alives are enabled and
connection timeout = 900 secs.

Additionally, we've tried setting the session timeout to 1 minute and after
the timeout - call session.abandon and response.redirect the client to the
start page to force the user to re-authenticate and populate session vars.

It seems that we can wipe out the session vars, but not the authentication.
We can see the HTTP headers from the client coming back with the old session
GUID.

Finally, we've tried sending a 401 header back to the client.  This does
force the logon, but the same user can't logon in the same browser window
for about 15 minutes.

If this is a bonehead issue on our part, I sure can't find out where...


How do we terminate the authentication and force the user to logon again?
Is the old session ID still valid after the abandon?


Thanks in advance,

Todd

[ Post a follow-up to this message ]

"Todd Johnson" <tjohnson@cgisenior.com> wrote in message
news:%23V7xl1DaEHA.2488@tk2msftngp13.phx.gbl...
> It seems that we can wipe out the session vars, but not the
authentication.
>
> How do we terminate the authentication and force the user to logon again?
> Is the old session ID still valid after the abandon?

That's because client authentication is not at all related to the ASP
session.  The browser caches the client credentials locally.  Aside from
closing the browser to kill the cache you may try:
http://support.microsoft.com/?kbid=195192

--
Tom Kaminski IIS MVP
http://www.microsoft.com/windowsser...ty/centers/iis/
http://mvp.support.microsoft.com/
http://www.iisfaq.com/
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://www.tryiis.com

[ Post a follow-up to this message ]

Thanks for the prompt response Tom!

I must say, though - that I'm a little disappointed in how IE handles this.
If the server sends a session.abandon then why aren't the credentials used
for that site either marked "dirty" or removed from the cache?

Our alternatives are not real pretty.  Closing the browser seems a bit
intrusive (and wouldn't we have to close ALL browser windows).   The client
component is also not ideal.  It does appear simple from a development
perspective, but it requires us to sign and install custom components on the
client in a time where many viruses and spyware components are also trying
to be installed on the client.

Most lay users may not understand the differences between malware components
and legitimate components.  Frequently, I simply advise users to either
disable activeX controls or at least prompt before install.  May also have
some issues with sites where ActiveX controls are disabled on the proxy or
firewall units.  So, this could be just a bunch of phone calls to our help
desk.  (We get several calls already with http vs https - so you can see
what our user population is like).

In summary, if these are our only alternatives - we'll probably use the
client side control.

Thanks again,

Todd


"Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
news:ccul50$d3u1@kcweb01.netnews.att.com...
> "Todd Johnson" <tjohnson@cgisenior.com> wrote in message
> news:%23V7xl1DaEHA.2488@tk2msftngp13.phx.gbl... 
> authentication. 
again?[vbcol=seagreen] 
>
> That's because client authentication is not at all related to the ASP
> session.  The browser caches the client credentials locally.  Aside from
> closing the browser to kill the cache you may try:
> http://support.microsoft.com/?kbid=195192
>
> --
> Tom Kaminski IIS MVP
> http://www.microsoft.com/windowsser...ty/centers/iis/
> http://mvp.support.microsoft.com/
> http://www.iisfaq.com/
> http://www.iistoolshed.com/ - tools, scripts, and utilities for running
IIS
> http://www.tryiis.com
>
>

[ Post a follow-up to this message ]

Todd,

you're confused about ASP sessions and HTTP authentication. They're not the
same thing. When you call Session.Abandon the session cookie will get
removed. But the session cookie has nothing to do with HTTP authentication.

Jerry

"Todd Johnson" <tjohnson@cgisenior.com> wrote in message
news:OCVhVqEaEHA.1656@TK2MSFTNGP09.phx.gbl...
> Thanks for the prompt response Tom!
>
> I must say, though - that I'm a little disappointed in how IE handles
> this.
> If the server sends a session.abandon then why aren't the credentials used
> for that site either marked "dirty" or removed from the cache?
>
> Our alternatives are not real pretty.  Closing the browser seems a bit
> intrusive (and wouldn't we have to close ALL browser windows).   The
> client
> component is also not ideal.  It does appear simple from a development
> perspective, but it requires us to sign and install custom components on
> the
> client in a time where many viruses and spyware components are also trying
> to be installed on the client.
>
> Most lay users may not understand the differences between malware
> components
> and legitimate components.  Frequently, I simply advise users to either
> disable activeX controls or at least prompt before install.  May also have
> some issues with sites where ActiveX controls are disabled on the proxy or
> firewall units.  So, this could be just a bunch of phone calls to our help
> desk.  (We get several calls already with http vs https - so you can see
> what our user population is like).
>
> In summary, if these are our only alternatives - we'll probably use the
> client side control.
>
> Thanks again,
>
> Todd
>
>
> "Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
> news:ccul50$d3u1@kcweb01.netnews.att.com... 
> again? 
> IIS 
>
>

[ Post a follow-up to this message ]