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)...

--

Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

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,

[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.
"Patrice" <a@bc.c> schreef in bericht
news:OC**************@TK2MSFTNGP14.phx.gbl...

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)...

--

Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

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,

[Edwin Knoppert]

tested again, indeed, even while i have persistance set to false, on browser
restart it never passes the login page.
"Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
news:43***********************@text.nova.planet.nl ...

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.
"Patrice" <a@bc.c> schreef in bericht
news:OC**************@TK2MSFTNGP14.phx.gbl...

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)...

--

Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

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]

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)..

--
Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

tested again, indeed, even while i have persistance set to false, on browser restart it never passes the login page.
"Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
news:43***********************@text.nova.planet.nl ...

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.
"Patrice" <a@bc.c> schreef in bericht
news:OC**************@TK2MSFTNGP14.phx.gbl...

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)...
--

Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...
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,

[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?
"Patrice" <a@bc.c> schreef in bericht
news:OU**************@TK2MSFTNGP12.phx.gbl...

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)..

--
Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

tested again, indeed, even while i have persistance set to false, on

browser

restart it never passes the login page.
"Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
news:43***********************@text.nova.planet.nl ...

> 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.
>
>
> "Patrice" <a@bc.c> schreef in bericht
> news:OC**************@TK2MSFTNGP14.phx.gbl...
>> 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)... >>
>> --
>>
>> Patrice
>>
>> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>> news:43***********************@text.nova.planet.nl ...
>>> 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,
>>>
>>>
>>>
>>
>>
>
>

[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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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?
"Patrice" <a@bc.c> schreef in bericht
news:OU**************@TK2MSFTNGP12.phx.gbl...

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)..

--
Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...

tested again, indeed, even while i have persistance set to false, on

browser

restart it never passes the login page.
"Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
news:43***********************@text.nova.planet.nl ...
> 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.
>
>
> "Patrice" <a@bc.c> schreef in bericht
> news:OC**************@TK2MSFTNGP14.phx.gbl...
>> 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)...

>>
>> --
>>
>> Patrice
>>
>> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>> news:43***********************@text.nova.planet.nl ...
>>> 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,
>>>
>>>
>>>
>>
>>
>
>

[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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP10.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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?
"Patrice" <a@bc.c> schreef in bericht
news:OU**************@TK2MSFTNGP12.phx.gbl...

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)..

--
Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...
tested again, indeed, even while i have persistance set to false, on
browser
restart it never passes the login page.
"Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
news:43***********************@text.nova.planet.nl ...
> 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.
>
>
> "Patrice" <a@bc.c> schreef in bericht
> news:OC**************@TK2MSFTNGP14.phx.gbl...
>> 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)...
>>
>> --
>>
>> Patrice
>>
>> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>> news:43***********************@text.nova.planet.nl ...
>>> 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,
>>>
>>>
>>>
>>
>>
>
>

[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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP10.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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?
"Patrice" <a@bc.c> schreef in bericht
news:OU**************@TK2MSFTNGP12.phx.gbl...
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)..

--
Patrice

"Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
news:43***********************@text.nova.planet.nl ...
> tested again, indeed, even while i have persistance set to false, on
browser
> restart it never passes the login page.
>
>
> "Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
> news:43***********************@text.nova.planet.nl ...
> > 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.
> >
> >
> > "Patrice" <a@bc.c> schreef in bericht
> > news:OC**************@TK2MSFTNGP14.phx.gbl...
> >> 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)...
> >>
> >> --
> >>
> >> Patrice
> >>
> >> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
> >> news:43***********************@text.nova.planet.nl ...
> >>> 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,
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

[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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP10.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...
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?
"Patrice" <a@bc.c> schreef in bericht
news:OU**************@TK2MSFTNGP12.phx.gbl...
> 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)..
>
> --
> Patrice
>
> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
> news:43***********************@text.nova.planet.nl ...
>> tested again, indeed, even while i have persistance set to false, on
> browser
>> restart it never passes the login page.
>>
>>
>> "Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
>> news:43***********************@text.nova.planet.nl ...
>> > 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.
>> >
>> >
>> > "Patrice" <a@bc.c> schreef in bericht
>> > news:OC**************@TK2MSFTNGP14.phx.gbl...
>> >> 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)...
>> >>
>> >> --
>> >>
>> >> Patrice
>> >>
>> >> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>> >> news:43***********************@text.nova.planet.nl ...
>> >>> 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,
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP10.phx.gbl...
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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...
>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?
>
>
> "Patrice" <a@bc.c> schreef in bericht
> news:OU**************@TK2MSFTNGP12.phx.gbl...
>> 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)..
>>
>> --
>> Patrice
>>
>> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>> news:43***********************@text.nova.planet.nl ...
>>> tested again, indeed, even while i have persistance set to false, on
>> browser
>>> restart it never passes the login page.
>>>
>>>
>>> "Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
>>> news:43***********************@text.nova.planet.nl ...
>>> > 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.
>>> >
>>> >
>>> > "Patrice" <a@bc.c> schreef in bericht
>>> > news:OC**************@TK2MSFTNGP14.phx.gbl...
>>> >> 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)...
>>> >>
>>> >> --
>>> >>
>>> >> Patrice
>>> >>
>>> >> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>>> >> news:43***********************@text.nova.planet.nl ...
>>> >>> 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,
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>

[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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP11.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...
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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP10.phx.gbl...
> 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" <ne**@hellobasic.com> wrote in message
> news:43***********************@text.nova.planet.nl ...
>>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?
>>
>>
>> "Patrice" <a@bc.c> schreef in bericht
>> news:OU**************@TK2MSFTNGP12.phx.gbl...
>>> 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)..
>>>
>>> --
>>> Patrice
>>>
>>> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message de
>>> news:43***********************@text.nova.planet.nl ...
>>>> tested again, indeed, even while i have persistance set to false,
>>>> on
>>> browser
>>>> restart it never passes the login page.
>>>>
>>>>
>>>> "Edwin Knoppert" <ne**@hellobasic.com> schreef in bericht
>>>> news:43***********************@text.nova.planet.nl ...
>>>> > 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.
>>>> >
>>>> >
>>>> > "Patrice" <a@bc.c> schreef in bericht
>>>> > news:OC**************@TK2MSFTNGP14.phx.gbl...
>>>> >> 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)...
>>>> >>
>>>> >> --
>>>> >>
>>>> >> Patrice
>>>> >>
>>>> >> "Edwin Knoppert" <ne**@hellobasic.com> a écrit dans le message
>>>> >> de
>>>> >> news:43***********************@text.nova.planet.nl ...
>>>> >>> 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,
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[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" <ne**@hellobasic.com> wrote in message
news:43**********************@text.nova.planet.nl. ..

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP11.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP10.phx.gbl...
> 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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
> news:%2******************@TK2MSFTNGP10.phx.gbl...
>> 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]

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:uw**************@tk2msftngp13.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43**********************@text.nova.planet.nl. ..

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP11.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...
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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP10.phx.gbl...
>> 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" <in**@pbsoft.speedlinq.nl> wrote in message
> news:dr**********@azure.qinip.net...
>> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
>> news:%2******************@TK2MSFTNGP10.phx.gbl...
>>> 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.

[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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:uw**************@tk2msftngp13.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43**********************@text.nova.planet.nl. ..

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP11.phx.gbl...
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" <ne**@hellobasic.com> wrote in message
news:43***********************@text.nova.planet.nl ...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
> news:%2****************@TK2MSFTNGP10.phx.gbl...
>>> 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" <in**@pbsoft.speedlinq.nl> wrote in message
>> news:dr**********@azure.qinip.net...
>>> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in
>>> bericht news:%2******************@TK2MSFTNGP10.phx.gbl...
>>>> 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]

Hehe :)

I might come back on this.

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2****************@TK2MSFTNGP15.phx.gbl...

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" <in**@pbsoft.speedlinq.nl> wrote in message
news:dr**********@azure.qinip.net...

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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:uw**************@tk2msftngp13.phx.gbl...

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" <ne**@hellobasic.com> wrote in message
news:43**********************@text.nova.planet.nl. ..
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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
news:%2******************@TK2MSFTNGP11.phx.gbl...
> 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" <ne**@hellobasic.com> wrote in message
> news:43***********************@text.nova.planet.nl ...
>> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in bericht
>> news:%2****************@TK2MSFTNGP10.phx.gbl...
>>>> 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" <in**@pbsoft.speedlinq.nl> wrote in message
>>> news:dr**********@azure.qinip.net...
>>>> 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" <ke***@DIESPAMMERSDIEtakempis.com> schreef in
>>>> bericht news:%2******************@TK2MSFTNGP10.phx.gbl...
>>>>> 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.