I googled "useuri", but nothing helpful turns up.

The forms authentication of my web application works perfectly if I
set

cookieless="UseDeviceProfile".

I want to test cookieless forms authentication, so in Web.config I
changed it to

cookieless="UseUri"

Apparently something else needs to be done in the code-behind if we do
UseUri, but I cannot find any documentation or helpful discussion
about this on the Web.

Any idea?

Thanks.

On Jan 25, 11:06 am, gnewsgroup <gnewsgr...@gmail.com> wrote:
> I googled "useuri", but nothing helpful turns up.
>
> The forms authentication of my web application works perfectly if I
> set
>
> cookieless="UseDeviceProfile".
>
> I want to test cookieless forms authentication, so in Web.config I
> changed it to
>
> cookieless="UseUri"
>
> Apparently something else needs to be done in the code-behind if we do
> UseUri, but I cannot find any documentation or helpful discussion
> about this on the Web.
>
> Any idea?
>
> Thanks.

Oh, I forgot to say what symptoms it has with cookieless=UseUri.

The symptom is: Right after a user logs in, he is immediately kicked
out to the same login page. Credentials are correct for sure.

no codebehind changes usually are required except with redirects. you should
be using relative or "~" urls. links can also be a problem.

this is because cookieless changes the url to have a login ticket. say your
site is:

http://localhost/mysite/default.aspx

in cookieless it becomes

http://localhost/mysite/<login ticket>/default.aspx

if your redirect does not include the login ticket, then the user is logged
out. you can use cookiesless sessions, and the session ticket is appended to
the authenication ticket.

-- bruce (sqlwork.com)


"gnewsgroup" wrote:

> I googled "useuri", but nothing helpful turns up.
>
> The forms authentication of my web application works perfectly if I
> set
>
> cookieless="UseDeviceProfile".
>
> I want to test cookieless forms authentication, so in Web.config I
> changed it to
>
> cookieless="UseUri"
>
> Apparently something else needs to be done in the code-behind if we do
> UseUri, but I cannot find any documentation or helpful discussion
> about this on the Web.
>
> Any idea?
>
> Thanks.
>

On Jan 25, 12:11 pm, bruce barker
<brucebar...@discussions.microsoft.com> wrote:
> no codebehind changes usually are required except with redirects. you should
> be using relative or "~" urls. links can also be a problem.
>
> this is because cookieless changes the url to have a login ticket. say your
> site is:
>
> http://localhost/mysite/default.aspx
>
> in cookieless it becomes
>
> http://localhost/mysite/<login ticket>/default.aspx
>
> if your redirect does not include the login ticket, then the user is logged
> out. you can use cookiesless sessions, and the session ticket is appended to
> the authenication ticket.
>
> -- bruce (sqlwork.com)
>

Thanks. Our client is cookie-phobic, even if it is encrypted and only
contains the username (which is public info anyway) and some
timestamp. So, I thought maybe I can do cookieless.

But, after reading some articles online, I find that cookieless
session may even be worse because the session id directly displays
itself in the URL (at least it is much easier to steal).

So, I guess my question becomes this:

Given that cookies are not allowed, what's the most secure way of
doing authentication? I don't want to go for the classic-asp approach
of checking the session value of USERNAME (for example) on each and
every single page. I am using asp.net 2.0.

you are confusing session and authentication. they are unrelated.

forms authentication create a login ticket and stores it in a cookie or the
url. session also creates a session ticket and stores it in a cookie or the
url. they can both use cookies, uri or be configured differently.

storing the login ticket in session just reduces the number of tickets sent
to the client.

cookie is slighty more secure (if you use https) because its not in the url.

the most secure is to not use forms authentication but rather a secure one
like kerberos or basic over https. then you store the login in the session,
and on every session fetch, check the the login matches the authenticated
user (thus preventing session hijacks)

-- bruce (sqlwork.com)


"gnewsgroup" wrote:

> On Jan 25, 12:11 pm, bruce barker
> <brucebar...@discussions.microsoft.com> wrote:
> > no codebehind changes usually are required except with redirects. you should
> > be using relative or "~" urls. links can also be a problem.
> >
> > this is because cookieless changes the url to have a login ticket. say your
> > site is:
> >
> > http://localhost/mysite/default.aspx
> >
> > in cookieless it becomes
> >
> > http://localhost/mysite/<login ticket>/default.aspx
> >
> > if your redirect does not include the login ticket, then the user is logged
> > out. you can use cookiesless sessions, and the session ticket is appended to
> > the authenication ticket.
> >
> > -- bruce (sqlwork.com)
> >
>
> Thanks. Our client is cookie-phobic, even if it is encrypted and only
> contains the username (which is public info anyway) and some
> timestamp. So, I thought maybe I can do cookieless.
>
> But, after reading some articles online, I find that cookieless
> session may even be worse because the session id directly displays
> itself in the URL (at least it is much easier to steal).
>
> So, I guess my question becomes this:
>
> Given that cookies are not allowed, what's the most secure way of
> doing authentication? I don't want to go for the classic-asp approach
> of checking the session value of USERNAME (for example) on each and
> every single page. I am using asp.net 2.0.
>

On Jan 25, 6:22*pm, bruce barker
<brucebar...@discussions.microsoft.com> wrote:
> you are confusing session and authentication. they are unrelated.
>
> forms authentication create a login ticket and stores it in a cookie or the
> url. session also creates a session ticket and stores it in a cookie or the
> url. they can both use cookies, uri or be configured differently.
>
> storing the login ticket in session just reduces the number of tickets sent
> to the client.
>
> cookie is slighty more secure (if you use https) because its not in the url.
>
> the most secure is to not use forms authentication but rather a secure one
> like kerberos or basic over https. then you store the login in the session,
> and on every session fetch, check the the login matches the authenticated
> user (thus preventing session hijacks)
>
> -- bruce (sqlwork.com)
>
>

Thank you very much for the clarification. Right now, I am storing
the authentication ticket in a cookie like so:

Session.Add("UserName", username);
FormsAuthenticationTicket ticket =
new FormsAuthenticationTicket(1, username, DateTime.Now,
DateTime.Now.AddMinutes(20), false, "someuserdatahere");
string encryptedTicket = FormsAuthentication.Encrypt(ticket);
HttpCookie cookie = new
HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Response.Cookies.Add(cookie);
Response.Redirect(FormsAuthentication.GetRedirectUrl(username,
false));

So, according to what you suggested, I could simply do:

Session.Add("authentication_ticket", encryptedTicket);

to stick it into the session and leave out the cookie part?