On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller <apa...@s05.tinita.de> wrote:
> On Wed, 16 Sep 2009, Michael Peters wrote: > > On 09/16/2009 12:13 PM, Brad Van Sickle wrote: >> >> Can I get you to explain this a little more? I don't see how this could >>> be used for truly secure sites because I don't quite understand how >>> storing a hash in a plain text cookie would be secure. >>> >> >> If you need to store per-session data about a client that the client >> shouldn't be able to see, then you just encrypt that data, base-64 encode it >> and then put it into a cookie. >> > > How does the user invalidate that "session"? (in case the cookie leaked > or something like that). Or how can the website owner log out a certain > user? > Same way you do with a table: when the user logs out, you update their cookie to a new one, where "userid" is not set. > If I have a session cookie with data in the server database I can always > invalidate that session by login out and thus removing the database > entry. > I personally prefer to have control over such things... > > Is one select per request that bad? if the website is completely > dynamic you will probably have other requests as well? > > Well, the cookie table is the one that gets hit a lot and grows out of control. It is hard to scale and replicate. Storing cookies on the browsers solves this completely. I can have a billion browsers connect to my site and no database growth will occur from that. > If you care about the number of selects you should IMHO better safe those > with the help of caching. >
