Otis wrote:
> David,
> Thanks for the reply. I was heading down the wrong path trying to reset the
> SessionID with Response.Cookies.Add(New HttpCookie("ASP.NET_SessionId", ""))
> and though that did force a new sessionid... it invalidated my hypothesis (as
> I believe you were hinting at by not addressing it).
> So, now it appears you are suggesting I either write a custom authentication
> protocol ( I might be up for that) or I make the browsers not auto-login ( I
> can specify that) while also having the Web Application CLOSE the connection.
>
> 1) Could you suggest a web site or book with examples on writing the custom
> authentication protocol please?
> 2) How does one CLOSE the connection programmatically from the Web
> Application?
> Thanks in advance for your reply!
> --
> Thanks,
> Otis
>
>
> "David Wang" wrote:
>
> > Actually, what you want to do is impossible with your current
> > constraints. You will have to write a custom authentication protocol to
> > get the behavior you want.
> >
> > And let's just leave your hypothesis alone - there are no
> > cookies/tokens involved; IIS has no idea what a session is; IIS does
> > not prompt with a login dialog.
> >
> > The problem you face is that a browser will automatically attempt
> > Integrated Authentication using the currently logged in Windows user
> > credentials to login to a website which is in a Zone configured for
> > auto login. And the server cannot do anything about it because logins
> > (and auto-login) is a client-side optimization.
> >
> > If you can control the browsers to not auto-login to your website, and
> > you can make your Web Application CLOSE the connection to logoff, then
> > you can get the behavior you want with Integrated Authentication
> > (NTLM). Integrated Authentication (Kerberos) is something different.
> >
> >
> > //David
> > http://w3-4u.blogspot.com
> > http://blogs.msdn.com/David.Wang
> > //
> >
> >
> > Otis wrote:
> > > I continue to research this and have hypothesized that what I'd really like
> > > to happen is to have IIS issue a NEW session id to the client once
> > > Session.Abandon is specified in my ASP.NET application. What appears to
> > > happen by default is that the Session ID remains the same after the abandon,
> > > but on the next connection IsNewSession is true. My hope is that when IIS
> > > sees a different SessionID it will again prompt for the user with a windows
> > > login dialog. Anyone got any feedback on this "guess"?
> > >
> > > Again,
> > > Otis
> > >
> > > --
> > > Thanks,
> > > Otis
> > >
> > >
> > > "Otis" wrote:
> > >
> > > > I'm trying to determine if it is possible to programmatically force an
> > > > already authenticated user (Using Integrated Windows Authentication) to login
> > > > again for my web site. I want them to be able to "logoff" for security
> > > > reasons and not have to close their browser. That way if someone sits at
> > > > their workstation and tries to link again to the site in question it will
> > > > prompt with the windows dialog again. Currently, if I try to "login" again
> > > > in the same browser it appears to already know who I am (a believe some
> > > > cookie or token is being held onto) and doesn't prompt me to login again.
> > > > Any ideas anyone?
> > > > --
> > > > Thanks,
> > > > Otis
> >
> >