forms authentication, cookieless?

[Lauchlan M]

Hi.

I want a login framework that uses the ASP.NET web.config / forms
authentication security schema (including roles in principals etc), but
operates cookieless.

What this means is I have to construct the authentication cookie, and I
guess I have to pass it around as a url variable eg something like (from
[url]http://www.codeproject.com/aspnet/cookieless.asp[/url] )

<<
FormsAuthenticationTicket tkt;
string cookiestr;
HttpCookie ck;

//create a valid ticket for forms authentication
tkt = new FormsAuthenticationTicket(1, userName, DateTime.Now,
DateTime.Now.AddMinutes(30), false, "your custom data");

//get the string representation of the ticket
cookiestr = FormsAuthentication.Encrypt(tkt);

//redirect to the return URL using the cookie in the address field
//In the web.config, we called out auth. ASPXFORMSAUTH2, so set that value
string strRedirect = Request["ReturnUrl"] + "?.ASPXFORMSAUTH2=" + cookiestr;
Response.Redirect(strRedirect, true);

>>

The other way suggested on that page - using an authenticated session
variable to confirm if a user is authenticated or not - doesn't work because
it doesn't tie in with the ASP.NET web.config schema and hence does not
provide directory level security unless one codes it manually by checking
the filepath in one of the Global.asax event handlers. The web.config file
will always bounce you back to Login.aspx because you never 'officially'
logged in, unless you get rid of the web.config authentication and
authorisation.

But passing the cookie around like that is really messy, and I'm not sure it
accomplishes anything since it is encrypted and I'm not sure anything reads
it or uses it in that form. Presumably you'd have to unpack it in one of the
the global.asax event handlers (eg the AuthenticateRequest one). It would be
much nicer if I could make the authentication ticket a session variable and
ASP.NET knew to look for it there when it is configured that way.

I could also use the Mobile stuff for forms authentication
([url]http://support.microsoft.com/default.aspx?scid=kb;%5bLN%5d;Q311568[/url]) , but
this does not appear to have a redirect method, only a redirect from login
method.

So I am fishing for a best method to tie in a cookieless login framework
with the ASP.NET forms authentication framework, which seems heavily
premised on using a cookie for the authentication ticket.

Any suggestions?

Lauchlan M

[Fredrik Normén NSQUARED2]

You can set the sessesionState element's cookieless
attribute to false in the configuration file. If
cookieless is set to false the session id will be added
to the URL.

<configuration>
<system.web>
<sessionState mode="Inproc"
cookieless="false"
timeout="20"/>
</sessionState>
</system.web>
</configuration>

/Fredrik Normén NSQUARED2
[url]http://www.nsquared2.net[/url]

>-----Original Message-----
>Hi.
>
>I want a login framework that uses the ASP.NET

web.config / forms

>authentication security schema (including roles in

principals etc), but

>operates cookieless.
>
>What this means is I have to construct the

authentication cookie, and I

>guess I have to pass it around as a url variable eg

something like (from

>[url]http://www.codeproject.com/aspnet/cookieless.asp[/url] )
>
><<
>FormsAuthenticationTicket tkt;
>string cookiestr;
>HttpCookie ck;
>
>//create a valid ticket for forms authentication
>tkt = new FormsAuthenticationTicket(1, userName,

DateTime.Now,

>DateTime.Now.AddMinutes(30), false, "your custom data");
>
>//get the string representation of the ticket
>cookiestr = FormsAuthentication.Encrypt(tkt);
>
>//redirect to the return URL using the cookie in the

address field

>//In the web.config, we called out auth. ASPXFORMSAUTH2,

so set that value

>string strRedirect = Request["ReturnUrl"]

+ "?.ASPXFORMSAUTH2=" + cookiestr;

>Response.Redirect(strRedirect, true);

>>>

>
>The other way suggested on that page - using an

authenticated session

>variable to confirm if a user is authenticated or not -

doesn't work because

>it doesn't tie in with the ASP.NET web.config schema and

hence does not

>provide directory level security unless one codes it

manually by checking

>the filepath in one of the Global.asax event handlers.

The web.config file

>will always bounce you back to Login.aspx because you

never 'officially'

>logged in, unless you get rid of the web.config

authentication and

>authorisation.
>
>But passing the cookie around like that is really messy,

and I'm not sure it

>accomplishes anything since it is encrypted and I'm not

sure anything reads

>it or uses it in that form. Presumably you'd have to

unpack it in one of the

>the global.asax event handlers (eg the

AuthenticateRequest one). It would be

>much nicer if I could make the authentication ticket a

session variable and

>ASP.NET knew to look for it there when it is configured

that way.

>
>I could also use the Mobile stuff for forms

authentication

>([url]http://support.microsoft.com/default.aspx?scid=kb;%5bLN%[/url]

5d;Q311568) , but

>this does not appear to have a redirect method, only a

redirect from login

>method.
>
>So I am fishing for a best method to tie in a cookieless

login framework

>with the ASP.NET forms authentication framework, which

seems heavily

>premised on using a cookie for the authentication ticket.
>
>Any suggestions?
>
>Lauchlan M
>
>
>.
>

[Lauchlan M]

<<
You can set the sessesionState element's cookieless
attribute to false in the configuration file.

>>

Surely you mean set cookieless to true?

This is what I do currently.

But this only handles passing the sessionID, not the authentication ticket.
It is this latter I need to figure out, the former is easy.

Thanks,

Lauchlan M

[Fredrik Normén www.NSQUARED2.net]

You can't use FormsAuthentications without cookies.

/Fredrik Normén NSQUARED2
[url]http://www.nsquared2.net[/url]

>-----Original Message-----
><<
>You can set the sessesionState element's cookieless
>attribute to false in the configuration file.

>>>

>
>Surely you mean set cookieless to true?
>
>This is what I do currently.
>
>But this only handles passing the sessionID, not the

authentication ticket.

>It is this latter I need to figure out, the former is

easy.

>
>Thanks,
>
>Lauchlan M
>
>
>.
>