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 doe
> "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
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'
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 s
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
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
sessi
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/
> "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 in
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
> "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, p
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 whe
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 architectur
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 nee
13 matches
Mail list logo
