FormsAuthentication.SignOut not working within subfolder

[Jeff Johnson]

I'm using forms authentication to protect a subfolder within my site. I've
got it working fine except for two issues:

(1) When I do a RedirectFromLogin page I have to put a cookie path ("/"
works, or "/mysubdir") or else the auth cookie doesn't get set. I'd like to
know why this is necessary.

(2) When I call SignOut() the auth cookie is not removed, no matter what I
try (no how the cookie is set in the RedirectFromLogin page.

My main web.config has the following entry:

<authentication mode="Forms">
<forms name="MyAdmin" path="admin" loginUrl="admin/adminlogin.aspx"
protection="All">
</forms>
</authentication>

The web.config within the "admin" directory looks like this:

<authorization>
<deny users="?" />
<allow users="*" />
</authorization>

As I said, everything works fine except the the SignOut does nothing:

FormsAuthentication.SignOut();
Response.Redirect(ConfigurationSettings.AppSetting s["SiteAdminAddress"],true
);

Any suggestions or any idea of a way to workaround this? I tried setting the
auth cookie "MyAdmin" value to nothing... but that didn't work.

Thanks!

[Lachlan James]

When you call RedirectFromLoginPage(string, bool) are you
passing false as the second argument so the cookie is not
persisted to the users computer?

Lachlan

>-----Original Message-----
>I'm using forms authentication to protect a subfolder

within my site. I've

>got it working fine except for two issues:
>
>(1) When I do a RedirectFromLogin page I have to put a

cookie path ("/"

>works, or "/mysubdir") or else the auth cookie doesn't

get set. I'd like to

>know why this is necessary.
>
>(2) When I call SignOut() the auth cookie is not removed,

no matter what I

>try (no how the cookie is set in the RedirectFromLogin

page.

>
>My main web.config has the following entry:
>
><authentication mode="Forms">
><forms name="MyAdmin" path="admin"

loginUrl="admin/adminlogin.aspx"

>protection="All">
></forms>
></authentication>
>
>The web.config within the "admin" directory looks like

this:

>
><authorization>
><deny users="?" />
><allow users="*" />
></authorization>
>
>As I said, everything works fine except the the SignOut

does nothing:

>
>FormsAuthentication.SignOut();
>Response.Redirect(ConfigurationSettings.AppSettin gs

["SiteAdminAddress"],true

>);
>
>Any suggestions or any idea of a way to workaround this?

I tried setting the

>auth cookie "MyAdmin" value to nothing... but that didn't

work.

>
>Thanks!
>
>
>
>.
>

[Jeff Johnson]

I've tried both true and false. I don't think this setting should affect the
SignOff process as signing off should clear the auth cookie regardless of
whether it is going to persist beyond the session or not. Any other ideas?

Thanks!

"Lachlan James" <NOlachlanSPAM@NOsmsiSPAM.com.au> wrote in message
news:099901c35b16$501a60e0$a101280a@phx.gbl...

> When you call RedirectFromLoginPage(string, bool) are you
> passing false as the second argument so the cookie is not
> persisted to the users computer?
>
> Lachlan
>

> >-----Original Message-----
> >I'm using forms authentication to protect a subfolder

> within my site. I've

> >got it working fine except for two issues:
> >
> >(1) When I do a RedirectFromLogin page I have to put a

> cookie path ("/"

> >works, or "/mysubdir") or else the auth cookie doesn't

> get set. I'd like to

> >know why this is necessary.
> >
> >(2) When I call SignOut() the auth cookie is not removed,

> no matter what I

> >try (no how the cookie is set in the RedirectFromLogin

> page.

> >
> >My main web.config has the following entry:
> >
> ><authentication mode="Forms">
> ><forms name="MyAdmin" path="admin"

> loginUrl="admin/adminlogin.aspx"

> >protection="All">
> ></forms>
> ></authentication>
> >
> >The web.config within the "admin" directory looks like

> this:

> >
> ><authorization>
> ><deny users="?" />
> ><allow users="*" />
> ></authorization>
> >
> >As I said, everything works fine except the the SignOut

> does nothing:

> >
> >FormsAuthentication.SignOut();
> >Response.Redirect(ConfigurationSettings.AppSettin gs

> ["SiteAdminAddress"],true

> >);
> >
> >Any suggestions or any idea of a way to workaround this?

> I tried setting the

> >auth cookie "MyAdmin" value to nothing... but that didn't

> work.

> >
> >Thanks!
> >
> >
> >
> >.
> >

[John Saunders]

Jeff, when you omit the path, it doesn't get "set", but are you sure it
doesn't get sent to the browser? Did you see the response message, and does
it have no Set-Cookie header?

--
John Saunders
Internet Engineer
[email]john.saunders@surfcontrol.com[/email]


"Jeff Johnson" <none@spam.com> wrote in message
news:fDBXa.619793$3C2.15212070@news3.calgary.shaw. ca...

> I'm using forms authentication to protect a subfolder within my site. I've
> got it working fine except for two issues:
>
> (1) When I do a RedirectFromLogin page I have to put a cookie path ("/"
> works, or "/mysubdir") or else the auth cookie doesn't get set. I'd like

to

> know why this is necessary.
>
> (2) When I call SignOut() the auth cookie is not removed, no matter what I
> try (no how the cookie is set in the RedirectFromLogin page.
>
> My main web.config has the following entry:
>
> <authentication mode="Forms">
> <forms name="MyAdmin" path="admin" loginUrl="admin/adminlogin.aspx"
> protection="All">
> </forms>
> </authentication>
>
> The web.config within the "admin" directory looks like this:
>
> <authorization>
> <deny users="?" />
> <allow users="*" />
> </authorization>
>
> As I said, everything works fine except the the SignOut does nothing:
>
> FormsAuthentication.SignOut();
>

Response.Redirect(ConfigurationSettings.AppSetting s["SiteAdminAddress"],true

> );
>
> Any suggestions or any idea of a way to workaround this? I tried setting

the

> auth cookie "MyAdmin" value to nothing... but that didn't work.
>
> Thanks!
>
>
>

[Jeff Johnson]

Well, if I remove the path, I just get bounced back to the login page again
after being forwarded. The cookies collection and headers (shown with Trace
enabled) show no auth cookie being set or transferred.

But...I just tried using SetAuthCookie instead of ReDirectFromLoginPage with
omitting the path and the cookie is showing up in the cookies collection but
not in the headers collection... and when I manually navigate to another
page I get bounced back as well. I don't know much about the relationship
between the cookies collection as shown in the trace and the headers). I
assume that if something is in the cookies collection but not returned from
the browser on the next page it disappers from the cookies collection as
well?

When I omit the path, I'm also getting two entries showing in the cookies
collection, one of them blank:

Cookies Collection

ASP.NET_SessionId nbduxfa22dzcmr55qzv5byqp42
AdminAuth
AdminAuth 10E1C44CA2D4F5139EDACF20704831B84BC372B0...

If I add the path back in "/" then I get one entry for the auth cookie in
both the cookies collection and header cookies ... but no signout (as
described previously).

And more ideas? :-)

TIA

"John Saunders" <john.saunders@surfcontrol.com> wrote in message
news:%23Re3%23Y5WDHA.2064@TK2MSFTNGP11.phx.gbl...

> Jeff, when you omit the path, it doesn't get "set", but are you sure it
> doesn't get sent to the browser? Did you see the response message, and

does

> it have no Set-Cookie header?
>
> --
> John Saunders
> Internet Engineer
> [email]john.saunders@surfcontrol.com[/email]
>
>
> "Jeff Johnson" <none@spam.com> wrote in message
> news:fDBXa.619793$3C2.15212070@news3.calgary.shaw. ca...

> > I'm using forms authentication to protect a subfolder within my site.

I've

> > got it working fine except for two issues:
> >
> > (1) When I do a RedirectFromLogin page I have to put a cookie path ("/"
> > works, or "/mysubdir") or else the auth cookie doesn't get set. I'd like

> to

> > know why this is necessary.
> >
> > (2) When I call SignOut() the auth cookie is not removed, no matter what

I

> > try (no how the cookie is set in the RedirectFromLogin page.
> >
> > My main web.config has the following entry:
> >
> > <authentication mode="Forms">
> > <forms name="MyAdmin" path="admin" loginUrl="admin/adminlogin.aspx"
> > protection="All">
> > </forms>
> > </authentication>
> >
> > The web.config within the "admin" directory looks like this:
> >
> > <authorization>
> > <deny users="?" />
> > <allow users="*" />
> > </authorization>
> >
> > As I said, everything works fine except the the SignOut does nothing:
> >
> > FormsAuthentication.SignOut();
> >

>

Response.Redirect(ConfigurationSettings.AppSetting s["SiteAdminAddress"],true

> > );
> >
> > Any suggestions or any idea of a way to workaround this? I tried setting

> the

> > auth cookie "MyAdmin" value to nothing... but that didn't work.
> >
> > Thanks!
> >
> >
> >

>
>

[Jeff Johnson]

Thanks for the suggestions, John!

Forms authentication is actually working fine when I use the root as the
path "/" (as mentioned in my first posting) so I don't want to spend too
much time fiddling with it. The problem is that SignOut isn't working...
which leads to me wonder if it is a framework bug. If the system is
accepting the cookie and allowing access to the pages, it obviously has no
problem with it. So can't it just nullify it?

I've tried changing the name of the cookie, to no effect.

Aha - I found a workaround. I simply set the value of the authentication
cookie to nothing. I assume that expiring the cookie now would have the same
effect.

Response.Cookies["AdminAuth"].Value = String.Empty;

I think the SignOut function is broken!

Thanks again!

Jeff

"John Saunders" <john.saunders@surfcontrol.com> wrote in message
news:OztwwH7WDHA.1492@TK2MSFTNGP12.phx.gbl...

> Jeff,
>
>
>
> You will need the path. I only mentioned removing it as an experiment.
>
>
>
> The thing to keep in mind about cookies is that it's up to the server to

ask

> the client to save them, but it's then up to the client to decide whether

or

> not to send them back to the server, and under what circumstances. Here

are

> some hints:
>
>
>
> 1) You should almost always include a domain. This tells the client
> what set of web sites to send the cookie back to. For instance, if you

have

> a site called [url]www.company.com[/url] and you set the domain to "company.com",

then

> the cookie will be sent to pages under [url]www.company.com[/url] or

press.company.com,

> but not to joeblow.com. The one time to use a blank domain is when you're
> working on localhost or something like that, when there is no domain to
> include. BTW, during your tests, always refer to your web site the same

way.

> Don't try [url]http://localhost/mysite[/url] once and then try

[url]http://mymachine/mysite[/url]

> or [url]http://mymachine.company.com/mysite[/url].
>
> 2) You should always set the path, but you should only set it to

"/".

> The path was originally meant to restrict what subset of your web site the
> cookie should be sent to. For instance, you should be able to set the path
> to "/press" and have the cookie sent to [url]http://www.company.com/press[/url] but

not

> to [url]http://www.company.com/sales[/url]. The problem is that the path is
> case-sensitive. So if you specify "/press" and your user types in

"/Press",

> the cookie will not be sent. This is why the path should always be set to
> "/".
>
> 3) If you do not set an expiration date, the cookie is a "session
> cookie". It will only last during the current browser session. Most users
> browsers will be set to accept session cookies from sites they visit, but
> some will not accept "permanent" cookies (I don't recall the opposite of
> "session" in this context!). Session cookies do not show up in Temporary
> Internet Files. When I have to be sure about whether and how a cookie is
> being set, I use a tool like ProxyTrace from [url]http://pocketsoap.com[/url] to

watch

> what headers are actually sent.
>
>
>
> Are you using the cookie name "AdminAuth" in any other part of your web
> application, or in some other web application? As an experiment, try
> changing the name of the cookie in web.config.
>
>
>
> I'd also suggest you add some extra tracing code in your Page_Load. Write

a

> "TraceCookies" subroutine to display the details of the cookies in the
> Request.Cookies collection. Be sure to display the name, domain, path and
> expiration. Using Page.Trace.Write to do this will add it to the same

place

> you're seeing the cookies collection now. Don't worry about the
> Request.Headers collection for now.
>
>
>
> I also suggest you limit your experimentation to a single set of pages and
> that you follow the same sequence each time. Start, try page requiring
> authentication, get sent to the login page, log in, and get bounced back

to

> the login page. Once you get this simple case to work, you can complicate
> things by seeing what happens with different pages, but for now, I'd keep

it

> simple.
>
> --
> John Saunders
> Internet Engineer
> [email]john.saunders@surfcontrol.com[/email]
>
>
> "Jeff Johnson" <none@spam.com> wrote in message
> news:YAXXa.632712$3C2.15425702@news3.calgary.shaw. ca...

> > Well, if I remove the path, I just get bounced back to the login page

> again

> > after being forwarded. The cookies collection and headers (shown with

> Trace

> > enabled) show no auth cookie being set or transferred.
> >
> > But...I just tried using SetAuthCookie instead of ReDirectFromLoginPage

> with

> > omitting the path and the cookie is showing up in the cookies collection

> but

> > not in the headers collection... and when I manually navigate to another
> > page I get bounced back as well. I don't know much about the

relationship

> > between the cookies collection as shown in the trace and the headers). I
> > assume that if something is in the cookies collection but not returned

> from

> > the browser on the next page it disappers from the cookies collection as
> > well?
> >
> > When I omit the path, I'm also getting two entries showing in the

cookies

> > collection, one of them blank:
> >
> > Cookies Collection
> >
> > ASP.NET_SessionId nbduxfa22dzcmr55qzv5byqp42
> > AdminAuth
> > AdminAuth 10E1C44CA2D4F5139EDACF20704831B84BC372B0...
> >
> > If I add the path back in "/" then I get one entry for the auth cookie

in

> > both the cookies collection and header cookies ... but no signout (as
> > described previously).
> >
> > And more ideas? :-)
> >
> > TIA
> >
> > "John Saunders" <john.saunders@surfcontrol.com> wrote in message
> > news:%23Re3%23Y5WDHA.2064@TK2MSFTNGP11.phx.gbl...

> > > Jeff, when you omit the path, it doesn't get "set", but are you sure

it

> > > doesn't get sent to the browser? Did you see the response message, and

> > does

> > > it have no Set-Cookie header?
> > >
> > > --
> > > John Saunders
> > > Internet Engineer
> > > [email]john.saunders@surfcontrol.com[/email]
> > >
> > >
> > > "Jeff Johnson" <none@spam.com> wrote in message
> > > news:fDBXa.619793$3C2.15212070@news3.calgary.shaw. ca...
> > > > I'm using forms authentication to protect a subfolder within my

site.

> > I've

> > > > got it working fine except for two issues:
> > > >
> > > > (1) When I do a RedirectFromLogin page I have to put a cookie path

> ("/"

> > > > works, or "/mysubdir") or else the auth cookie doesn't get set. I'd

> like

> > > to
> > > > know why this is necessary.
> > > >
> > > > (2) When I call SignOut() the auth cookie is not removed, no matter

> what

> > I

> > > > try (no how the cookie is set in the RedirectFromLogin page.
> > > >
> > > > My main web.config has the following entry:
> > > >
> > > > <authentication mode="Forms">
> > > > <forms name="MyAdmin" path="admin" loginUrl="admin/adminlogin.aspx"
> > > > protection="All">
> > > > </forms>
> > > > </authentication>
> > > >
> > > > The web.config within the "admin" directory looks like this:
> > > >
> > > > <authorization>
> > > > <deny users="?" />
> > > > <allow users="*" />
> > > > </authorization>
> > > >
> > > > As I said, everything works fine except the the SignOut does

nothing:

> > > >
> > > > FormsAuthentication.SignOut();
> > > >
> > >

> >

>

Response.Redirect(ConfigurationSettings.AppSetting s["SiteAdminAddress"],true

> > > > );
> > > >
> > > > Any suggestions or any idea of a way to workaround this? I tried

> setting

> > > the
> > > > auth cookie "MyAdmin" value to nothing... but that didn't work.
> > > >
> > > > Thanks!
> > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>