persistant cookie, what is it?

[Edwin Knoppert]

I have searched but info is limitted.

In my test app i used a non persistant cookie for forms authentication.
slidingExpiration is set to true

On run and close and rerun the login remains ok.

I have a time-out of one minute and indeed, it directs me to the login if i
wait to long.
The slidingExpiration does it's work also.

So were is this persistance for?

Thanks,

 

[Patrice]

What do you mean by "close" ? A non persistant cookie shouldn't survive when
the browser is closed and launched again (unlike a persistant cookie)...

 

[Edwin Knoppert]

Well it does..

And indeed i mean run, close the browser, and run again.
But then this was all tested in the VWD environment.

What you are telling me is what i expected.
In our case we might choose for non-persistance.

 

[Edwin Knoppert]

tested again, indeed, even while i have persistance set to false, on browser
restart it never passes the login page.

 

[Patrice]

You can see the cookies for the site in the browser options to make sure
this is not another problem (for example an non protected page)..

 

[Edwin Knoppert]

I have checked, my options guides me to the folder: .....Local
Settings\Temporary Internet Files
I cleaned most of it, cookies do not show a name i used for test: <forms
name="AuthCookie_logintest1" ...
I assume the cookie *filename* contains the forms name somehow?

Yes, i'm using roles, it all works out fine, i checked with isinrole() on a
2nd webpage.
To authenicate i'm using:

Dim authTicket As FormsAuthenticationTicket = New
FormsAuthenticationTicket(1, sUserName, DateTime.Now, Expiration,
bIsPersistant, sRoles)
Where bIsPersistant is false (checked).

I even terminated the local webserver, the one executed by VWD.

But since i do not persist, i don't think there is a filename right?

 

[Kevin Spencer]

Why don't you use Session State? It behaves exactly the same (except for
timing out), and in fact, when it uses cookies, it uses a non-persistent
("session") cookie to identify the client.

More information: All you need to do to not persist a cookie is not to set
the Expiration property. This creates a session cookie on the client, which
is not stored in the file system, but in browser memory. The difference
between using a session cookie on the client,and using Session State, is
that Session State times out. The client session cookie will remain on the
client until the domain is navigated away from, or the browser is closed.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Edwin Knoppert]

I'll look into that tomorrow.

I had a heavy discussion last week that colleagues of mine are misusing
session variables.
I don't want, if the session expires, the user get's bothered to log in
again.
I know, authentication is NOT session related, but my colleagues are
misusing the session object to store a user id into.
I have hard time to talk them into better use.
If the session expires and your o so precious variable got lost, make sure
you reload it and let the client continue with it's request.

But.. i got warned that they don't want to keep authentication 'open' for a
long period of time.
I used to set a month ahead and the auto-expire-increase stuff (forgot) so
the user was never bothered with a login again.
But now they want to use a time-out and force a login.
So i tested it today how it behavious.
Fine by me, important to me is that they should understand the session stuff
first.

Am i right on this?

 

[Kevin Spencer]

Am i right on this?

I would say yes. In fact, since you are wanting a timeout, Session is
actually the best solution for you.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Edwin Knoppert]

But.. that's quiet the opposite to what i meant.

I mean, you could use this 'trick' via a session but what i want is that the
session is not used for kinds of stuff.
The expiration of the authentication is not involved with the session so one
actually should use the authentication stuff to reach his goal right?

Expiration in a cookie can work the same as session expiring.
Like i said, using the session and making the client depending on it is a
bad approach imo.

 

[Kevin Spencer]

I'm not sure what problem you have with Session State. It is there for a
purpose. "imo" is not a logical reason for doing or not doing something. An
opinion is a poor substitute for a fact. The fact that Session times out
makes it eminently suitable for any user-specific temporary data storage
that should expire within a given time span. That is what it was designed
for.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Edwin Knoppert]

We have a miscommunication.
I agree on the session state, i read about it, the "sqlserver" solution
might be a good option.

I simply mentioned that the end-user shouldn't be bothered with unwanted
time-outs.
Iow, if a session has a timeout, a new request must be able to produce the
request.

The login stuff, another issue, should never rely on a session object.
If you need a time-out on a authentication, don't use the session but make
sure the authentication itselfs has a time-out.
It's a vision of mine not to use the session object in such a way the user
get's bothered.

When i access hotmail and i go to diner and come back i can continue, unless
my cookie has expired, which is a month or so

 

[Kevin Spencer]

Hi Edwin,

Perhaps I'm just misunderstanding your requirements. When you said "now they
want to use a time-out and force a login" I understood you to mean that a
literal timeout would be necessary. But when you say "When i access hotmail
and i go to diner and come back i can continue, unless my cookie has
expired, which is a month or so" I understand you to say that you do *not*
need to use a timeout.

Here's the crux of the issue: If you want to timeout the user during a
browser session, Session State is the way to go. If you want to not require
the user to log in for a month, a persistent cookie is the way to go. If you
want the user to not time out, but to be logged out when he/sh closes the
browser, a non-persistent (session) cookie is the way to go.

Again, I don't understand what your requirements are. However, here are some
security considerations to take into account when creating requirements.

If you use anything but a server timeout (such as Session) you take a
security risk. For example, if you use a session cookie, which does not
expire as long as the browser remains opened, the user can leave, and
another person can come and work on the same computer with that user's
stuff. This is even worse if you set the expiration for some date in the
future, as anyone that browses to the domain on that computer will be
automatically logged in.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Edwin Knoppert]

Thanks,

I'm do not entirly agree, in this case yes but if an app is critical, like
finacial/private or so, for myself i abandon my making use of signoff()
stuff.
Like i said, i was used to cookies set for a month, now i set it to
15minutes and slidingexpiration.
So that 'could' be seen simialr to session expiring.
If you leave the computer and someone can start the browser and continue..
well it's their choice to leave the browser unprotected.

But now i think of it.. maybe the cookieless or similar stuff is the best
thing to do.
I have no experiance with that yet but i wouldn't see an odd session id in
my url..

Still, to be persistant, i would not use the session to be the time-out, it
has nothing to do with authentication, maybe internally or indirect but not
for me as programmer.
If the admin chooses to increase or decrease session time-out i would not
want to be depending on that for the authentication matter.
Even so, if we would be 'superfriendly' we even could ask the client for a
authentication time-out.
yes, that would then require a cookie to be stored.. i know.

Authentication ISNOT session... clear?

 

[Kevin Spencer]

Authentication ISNOT session... clear?

Not really. That's sort of like saying that a chimney is not like a brick.

But as long as *you're* clear, that's all that matters!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Who is Mighty Abbott?
A twin turret scalawag.

 

[Edwin Knoppert]

Hehe

I might come back on this.

Not really. That's sort of like saying that a chimney is not like a brick.

But as long as *you're* clear, that's all that matters!

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Who is Mighty Abbott?
A twin turret scalawag.