Re: Updating cookies in header during request processing
On 09/18/2009 12:57 PM, Randal L. Schwartz wrote: The problem with that is public web browsers. You *cannot* ensure the expiration of an auth cookie, so you'll have to have some sort of server-side data to say "this user most recently authenticated at this time, so I still trust him". Why does this have to be server side? Why can't it be part of the cookie's (tamper proof) data itself? -- Michael Peters Plus Three, LP
Re: Updating cookies in header during request processing
> "Igor" == Igor Chudov writes: Igor> In my case, in almost all instances, the only thing I would want to Igor> store is authenticated userid. The problem with that is public web browsers. You *cannot* ensure the expiration of an auth cookie, so you'll have to have some sort of server-side data to say "this user most recently authenticated at this time, so I still trust him". And once you've done that, why store *any* auth client side? Just brand the browser, as my article says. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Re: Updating cookies in header during request processing
On Fri, Sep 18, 2009 at 10:51 AM, Michael Peters wrote: > On 09/18/2009 11:15 AM, James Smith wrote: > > But cookies are in general not big enough to store the information that >> a user would store on a website! >> > > I'm not talking about eliminating a permanent data store for your users. > I'm talking about replacing the session specific things. How much session > specific data do you really need to store? If it's bigger than 4K per-user > than yes you can't use a single cookie. But like I said before, the > situations that you really need more than that for *session specific* data > are pretty rare. > In my case, in almost all instances, the only thing I would want to store is authenticated userid. But I cannot exclude other possibilities. Right now I use Apache::Session to store a hash in a mysql table "sessions". I have a "users" table that holds their profile information such as their email, their picture, etc. If I can find a way to set that cookie after the request is processed, I would be very happy. I can _probably_ work around it and set cookie before doing start_html, but I would prefer not to. Regarding another comment on using templates, etc: I have basically a homegrown CMS on algebra.com. And I do support templates: the presentation is mostly decoupled from content, such as where ads are places, how navigation aids are presented etc, is all decoupled. I can work on the new template for a month and the users will not notice as they will see the old template. But I like what I have as it is my own. Igor
Re: Updating cookies in header during request processing
Hi Randal, nice to see you. Your suggestion is where I am coming FROM: right now the cookie is only a key into the mysql table which holds session data. What I want is to stop using that table altogether and let the browser hold the information, in a manner that is straightforward, flexible and secure. Igor On Fri, Sep 18, 2009 at 9:33 AM, Randal L. Schwartz wrote: > > "Igor" == Igor Chudov writes: > > Igor> I was very excited by the suggestion to use cookies to store the > entire > Igor> session information, and to keep it safe by means of base64 encoding > and > Igor> MD5 hash with a secret salt, for storing session information securely > on > Igor> the client. > > Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize > that > cookies should really just be used to distinguish one browser from another, > and hold everything server-side instead for far better security and > flexibility. (Remember, server-side could be something as simple as > DBM::Deep, which is a single-file zero-install module that gives you > arbitrary persistent Perl data structures efficiently.) > > See my (slightly aged but still valid) write-up of this at: > > http://www.stonehenge.com/merlyn/WebTechniques/col61.html > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside > discussion >
Re: Updating cookies in header during request processing
On 09/18/2009 11:19 AM, Randal L. Schwartz wrote: Yes. Welcome to phase 2. Eventually, you'll enter phase 3. I used to be a phase 3 convert and then some really smart people convinced me otherwise :) -- Michael Peters Plus Three, LP
Re: Updating cookies in header during request processing
On 09/18/2009 11:15 AM, James Smith wrote: But cookies are in general not big enough to store the information that a user would store on a website! I'm not talking about eliminating a permanent data store for your users. I'm talking about replacing the session specific things. How much session specific data do you really need to store? If it's bigger than 4K per-user than yes you can't use a single cookie. But like I said before, the situations that you really need more than that for *session specific* data are pretty rare. and security is not just on your server (but also on the clients machine) so if the browser can read it - anyone that can compromise the browser can also read it - if it is on the server that is harder! It's almost as if people aren't reading my other emails :) If you need to prevent tampering, use a hash. If you need to completely secure the data, encrypt it. -- Michael Peters Plus Three, LP
Re: Updating cookies in header during request processing
All due respect, but hat's a little condescending... I generally cringe when I hear anyone advocating that there is one "right" way to do things that should be used in every instance In addition to Michael's points (which are totally valid) I would add that your solution is great for small/medium sized sites but as soon as you scale into sites with very large amounts of traffic it quickly raises a lot of operational concerns about where to store that data in place that's retrievable in a short enough time frame to not degrade performance. Solving that problem is going to cost time and money and will sometimes result in your application caring about session affinity, which is another operational concern. I'm not saying that these problems aren't solvable, I'm simply saying that I don't think it's nearly as cut and dried as you seem to, especially when you look at the app from and operational perspective. I can see both sides of this argument and I can see situations in in which either solution might be advantageous over the other. A lot depends on budget, environmental layout, how often the session is updated, how much data you're storing, etc... Perhaps you could outline in a little more detail why you think storing everything server side is the only "right" way to do things? Randal L. Schwartz wrote: "Michael" == Michael Peters writes: Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote: Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that cookies should really just be used to distinguish one browser from another, and hold everything server-side instead for far better security and flexibility. Michael> I disagree. Using cookies for session data has a lot of advantages: [justifications snipped] Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter webdev people always do. I sounded exactly like you, once, and then grew out of it. The more you resist, the longer your delay. :)
Re: Updating cookies in header during request processing
> "Michael" == Michael Peters writes: Michael> On 09/18/2009 10:33 AM, Randal L. Schwartz wrote: >> Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that >> cookies should really just be used to distinguish one browser from another, >> and hold everything server-side instead for far better security and >> flexibility. Michael> I disagree. Using cookies for session data has a lot of advantages: [justifications snipped] Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter webdev people always do. I sounded exactly like you, once, and then grew out of it. The more you resist, the longer your delay. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Re: Updating cookies in header during request processing
On 09/18/2009 10:33 AM, Randal L. Schwartz wrote: Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that cookies should really just be used to distinguish one browser from another, and hold everything server-side instead for far better security and flexibility. I disagree. Using cookies for session data has a lot of advantages: + No need to have a permanent data store (DBD::Deep is single server only and why waste the resources to go across the network to your DB or cache if you don't have to). Also no need to clean up this data store periodically. Having a single source for this data also kills scalability. + If it's commonly used data, putting it into a cookie will make it available to the client side Javascript. Why waste server resources to do what the client's machine can do. In fact, I find it's more flexible to have this information in the cookie since my front end folks can then use it to add functionality without having to trouble the back end folks. And securing a cookie is pretty easy. If the information is not sensitive then you just need to put a hash in it to make sure it's not tampered with. If it is sensitive, then encryption works for cookies too. I'm not saying there aren't uses for large server side sessions, but I think they are pretty few. -- Michael Peters Plus Three, LP
Re: Updating cookies in header during request processing
> "Igor" == Igor Chudov writes: Igor> I was very excited by the suggestion to use cookies to store the entire Igor> session information, and to keep it safe by means of base64 encoding and Igor> MD5 hash with a secret salt, for storing session information securely on Igor> the client. Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that cookies should really just be used to distinguish one browser from another, and hold everything server-side instead for far better security and flexibility. (Remember, server-side could be something as simple as DBM::Deep, which is a single-file zero-install module that gives you arbitrary persistent Perl data structures efficiently.) See my (slightly aged but still valid) write-up of this at: http://www.stonehenge.com/merlyn/WebTechniques/col61.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Re: Updating cookies in header during request processing
On Fri 18 Sep 2009, Igor Chudov wrote: > But how can I change the cookie AFTER I called $cgi->start_html? As long as there is nothing sent out on the wire you can add headers. When the response header is gone you can't. start_html() only generates a string as far as know. So it depends upon when this string is sent. But with mod_perl you can circumvent even this limitation. Write a caching output filter. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: Updating cookies in header during request processing
On 09/18/2009 09:14 AM, Igor Chudov wrote: I realized that there is something I am missing. Sometimes I may need to put something into the session after I did $cgi->start_html. I can do it if the cookie is only a session ID, with session data stored in mysql. This might be a larger architectural problem them. IMO, you really shouldn't use CGI.pm for HTML generation. Most people use a template of some sort for that. And the next thing would be to reorganize your code so that you aren't tied to a specific order of doing things. For instance, I normally use CGI::Application which lets me do all kinds of things to the headers and content until I'm all ready to return at the end of my run mode. The order doesn't matter. But how can I change the cookie AFTER I called $cgi->start_html? Since cookies are part of the HTTP headers they need to go out before any HTML content. So instead of just printing the content as you go, why don't you collect your HTML into a variable and then print it all out at the end. -- Michael Peters Plus Three, LP
Updating cookies in header during request processing
I was very excited by the suggestion to use cookies to store the entire session information, and to keep it safe by means of base64 encoding and MD5 hash with a secret salt, for storing session information securely on the client. I realized that there is something I am missing. Sometimes I may need to put something into the session after I did $cgi->start_html. I can do it if the cookie is only a session ID, with session data stored in mysql. But how can I change the cookie AFTER I called $cgi->start_html? If I can do that, I think that I am set to go. thanks Igor
