On 4 Mar 2008, at 13:57, Jochem Maas wrote:
> Stut mentioned a little while back that he avoids using the built-in
> session

> mechanism if at all possible, but still manages to track user
> state ... now I
> can think of a way or two that he might do that but I was wondering if
> any one could give an idea about the write way to do it in terms of
> high performance :-)

Finally found time to finish the article, sorry for the delay...

http://stut.net/articles/sessionless_sessions.html

Constructive criticism welcome.

-Stut

--
http://stut.net/

-----Mensagem original-----
De: Stut [mailto:stuttle@gmail.com]


On 4 Mar 2008, at 13:57, Jochem Maas wrote:
> Stut mentioned a little while back that he avoids using the built-in
> session

> mechanism if at all possible, but still manages to track user state
> ... now I can think of a way or two that he might do that but I was
> wondering if any one could give an idea about the write way to do it
> in terms of high performance :-)

Finally found time to finish the article, sorry for the delay...

http://stut.net/articles/sessionless_sessions.html

Constructive criticism welcome.

-Stut

<me>
Good one, but how about CPU Load? Did it increase much?

</me>

On 11 Mar 2008, at 13:31, Thiago Pojda wrote:
> -----Mensagem original-----
> De: Stut [mailto:stuttle@gmail.com]
>
>
> On 4 Mar 2008, at 13:57, Jochem Maas wrote:
>> Stut mentioned a little while back that he avoids using the built-in
>> session
>
>> mechanism if at all possible, but still manages to track user state
>> ... now I can think of a way or two that he might do that but I was
>> wondering if any one could give an idea about the write way to do it
>> in terms of high performance :-)
>
> Finally found time to finish the article, sorry for the delay...
>
> http://stut.net/articles/sessionless_sessions.html
>
> Constructive criticism welcome.
>
> <me>
> Good one, but how about CPU Load? Did it increase much?
>
> </me>

Not really. The is far more more memory and network-bound than CPU-
bound.

It's not an excessively strong cipher so I doubt it has much effect at
all, especially when compared to the expense of fetching from a DB
server.

-Stut

--
http://stut.net/

2008. 03. 11, kedd keltezéssel 12.34-kor Stut ezt Ãrta:
> On 4 Mar 2008, at 13:57, Jochem Maas wrote:
> > Stut mentioned a little while back that he avoids using the built-in
> > session
>
> > mechanism if at all possible, but still manages to track user
> > state ... now I
> > can think of a way or two that he might do that but I was wondering if
> > any one could give an idea about the write way to do it in terms of
> > high performance :-)
>
> Finally found time to finish the article, sorry for the delay...
>
> http://stut.net/articles/sessionless_sessions.html
>
> Constructive criticism welcome.

good article. I've also realized long ago that I only need user id in to
be stored in the session, and also considered storing that in some
encrypted , so I might just take and use your solution if you
don't mind

greets,
Zoltán Németh

>
> -Stut
>
> --
> http://stut.net/
>
>

On 11 Mar 2008, at 14:26, Zoltán Németh wrote:
> 2008. 03. 11, kedd keltezéssel 12.34-kor Stut ezt írta:
>> On 4 Mar 2008, at 13:57, Jochem Maas wrote:
>>> Stut mentioned a little while back that he avoids using the built-in
>>> session
>>
>>> mechanism if at all possible, but still manages to track user
>>> state ... now I
>>> can think of a way or two that he might do that but I was
>>> wondering if
>>> any one could give an idea about the write way to do it in terms of
>>> high performance :-)
>>
>> Finally found time to finish the article, sorry for the delay...
>>
>> http://stut.net/articles/sessionless_sessions.html
>>
>> Constructive criticism welcome.
>
> good article. I've also realized long ago that I only need user id
> in to
> be stored in the session, and also considered storing that in some
> encrypted , so I might just take and use your solution if you
> don't mind

Thanks, and be my guest - that's why I wrote it up!

-Stut

--
http://stut.net/

That's a really interesting post; I was bound to come up with that
problem soon. Thanks!

At 12:34 PM +0000 3/11/08, Stut wrote:
>On 4 Mar 2008, at 13:57, Jochem Maas wrote:
>>Stut mentioned a little while back that he avoids using the built-in session
>
>>mechanism if at all possible, but still manages to track user state ... now I
>>can think of a way or two that he might do that but I was wondering if
>>any one could give an idea about the write way to do it in terms of
>>high performance :-)
>
>Finally found time to finish the article, sorry for the delay...
>
>http://stut.net/articles/sessionless_sessions.html
>
>Constructive criticism welcome.

Stut:

Nice article.

I'm currently working on one large site and I only pass the user's id
from page to page in session. All other data is pulled from the
database as needed. But, I've never had a problem that spanned
several servers. The idea was simply to call-in for the data needed
rather than carry baggage around.

I have noticed that eBay uses a similar technique for different
states of a user (un-confirmed, revisiting, and confirmed) via a
.

I question the reason why you would want to encrypt the
considering that before the user is going to be provided access to
sensitive data that you require a password confirmation. The
encryption seems to be an unnecessary overkill.

So what if a malicious user uses a to pretend to be a real
user IF before they can get access to sensitive data they have to
enter a correct password?

Please explain.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

tedd wrote:
> Nice article.

Thanks.

> I question the reason why you would want to encrypt the
> considering that before the user is going to be provided access to
> sensitive data that you require a password confirmation. The encryption
> seems to be an unnecessary overkill.
>
> So what if a malicious user uses a to pretend to be a real user
> IF before they can get access to sensitive data they have to enter a
> correct password?
>
> Please explain.

Certainly. It's not about them getting access to the data in that
, it's got more to do with ensuring the contents remain
unchanged.

While it's true that the "remember me" could live with not being
encrypted I would then need to validate the data it contains. By
encrypting it I know that if it decrypts successfully it's exactly what
the site put in it at the end of the last request.

For some sites this would not be an issue but due to some of the ways we
use the data in that I decided the cost of encrypting it against
the cost of validating it and the risks involved made encryption the
better option.

There is another reason... are sometimes stored in plain text on
the users machine. Since that contains an email address and
potentially a phone number it's much better to encrypt it and protect
our users.

Hope that answers your question.

-Stut

--
http://stut.net/

At 3:16 PM +0000 3/13/08, Stut wrote:
>tedd wrote:
>>Nice article.
>
>Thanks.
>
>>I question the reason why you would want to encrypt the
>>considering that before the user is going to be provided access to
>>sensitive data that you require a password confirmation. The
>>encryption seems to be an unnecessary overkill.
>>
>>So what if a malicious user uses a to pretend to be a real
>>user IF before they can get access to sensitive data they have to
>>enter a correct password?
>>
>>Please explain.
>
>Certainly. It's not about them getting access to the data in that
>, it's got more to do with ensuring the contents remain
>unchanged.
>
>While it's true that the "remember me" could live with not
>being encrypted I would then need to validate the data it contains.
>By encrypting it I know that if it decrypts successfully it's
>exactly what the site put in it at the end of the last request.
>
>For some sites this would not be an issue but due to some of the
>ways we use the data in that I decided the cost of encrypting
>it against the cost of validating it and the risks involved made
>encryption the better option.
>
>There is another reason... are sometimes stored in plain
>text on the users machine. Since that contains an email
>address and potentially a phone number it's much better to encrypt
>it and protect our users.
>
>Hope that answers your question.
>
>-Stut

Okay.

Considering that all user data is placed in a database for extraction
as needed, then why not put the state of the user's last visit in
there as well and save only the session id (or whatever) as a ?

Then, when the user returns, you simply check the with what's
stored in the dB and continue as before. If the check fails (no
session id or it has been altered), then start again.

To do house keeping, simply run a routine at some interval to check
the sessions' age and remove those that are older than what's wanted.

Why put anything client-side that might be a security problem?

Cheers,

tedd


--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

tedd wrote:
> At 3:16 PM +0000 3/13/08, Stut wrote:
>> tedd wrote:
>>> I question the reason why you would want to encrypt the
>>> considering that before the user is going to be provided access to
>>> sensitive data that you require a password confirmation. The
>>> encryption seems to be an unnecessary overkill.
>>>
>>> So what if a malicious user uses a to pretend to be a real
>>> user IF before they can get access to sensitive data they have to
>>> enter a correct password?
>>>
>>> Please explain.
>>
>> Certainly. It's not about them getting access to the data in that
>> , it's got more to do with ensuring the contents remain
>> unchanged.
>>
>> While it's true that the "remember me" could live with not
>> being encrypted I would then need to validate the data it contains. By
>> encrypting it I know that if it decrypts successfully it's exactly
>> what the site put in it at the end of the last request.
>>
>> For some sites this would not be an issue but due to some of the ways
>> we use the data in that I decided the cost of encrypting it
>> against the cost of validating it and the risks involved made
>> encryption the better option.
>>
>> There is another reason... are sometimes stored in plain text
>> on the users machine. Since that contains an email address and
>> potentially a phone number it's much better to encrypt it and protect
>> our users.
>>
>> Hope that answers your question.
>
> Okay.
>
> Considering that all user data is placed in a database for extraction as
> needed, then why not put the state of the user's last visit in there as
> well and save only the session id (or whatever) as a ?
>
> Then, when the user returns, you simply check the with what's
> stored in the dB and continue as before. If the check fails (no session
> id or it has been altered), then start again.

Because that negates the whole point of doing it which is to reduce
database access to the minimum possible.

> To do house keeping, simply run a routine at some interval to check the
> sessions' age and remove those that are older than what's wanted.
>
> Why put anything client-side that might be a security problem?

IMHO the encryption reduces the security risk to a more-than-acceptable
level, and it saves a shed load of database calls to the point where
most page requests (~70%) don't touch the database at all which is what
I was aiming for.

-Stut

--
http://stut.net/

At 4:01 PM +0000 3/13/08, Stut wrote:
>tedd wrote:
>>Then, when the user returns, you simply check the with
>>what's stored in the dB and continue as before. If the check fails
>>(no session id or it has been altered), then start again.
>
>Because that negates the whole point of doing it which is to reduce
>database access to the minimum possible.

Oops, I guess I missed the whole point of your article.

You want to minimize dB usage by using an encrypted so that
when users return, that action doesn't use the dB.

But, once the user is on, then everything they request in the form of
unique data is provided by the dB via their user id, correct? So, you
saved one trip to the store, but how many trips to the store does a
user usually make? And is that worth it?

Not being critical, just wondering.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

tedd wrote:
> At 4:01 PM +0000 3/13/08, Stut wrote:
>> tedd wrote:
>>> Then, when the user returns, you simply check the with what's
>>> stored in the dB and continue as before. If the check fails (no
>>> session id or it has been altered), then start again.
>>
>> Because that negates the whole point of doing it which is to reduce
>> database access to the minimum possible.
>
> Oops, I guess I missed the whole point of your article.
>
> You want to minimize dB usage by using an encrypted so that when
> users return, that action doesn't use the dB.
>
> But, once the user is on, then everything they request in the form of
> unique data is provided by the dB via their user id, correct? So, you
> saved one trip to the store, but how many trips to the store does a user
> usually make? And is that worth it?
>
> Not being critical, just wondering.

As I state in the article most of the site is the same for all users
whether logged in or not. If the user is logged in then we should a menu
in the left column which displays their name. We also pre-fill some
forms with their name, email address and phone number.

That means that to remove the need to access the DB on every request for
logged in users on most of the site we just need to store their name,
email address and phone number between requests in a way that doesn't
involve the database. That is the problem the technique in the article
solves.

It's true to say that when the user is in the members area most page
requests will need to hit the DB, but as stated that amounts to less
than 30% of page views on any given day. The end result is that DB load
is now at an acceptable level without compromising the user experience.

Hope that makes sense now. If not I'm happy to explain further.

-Stut

--
http://stut.net/