Re: [OT-ish] Session refresh philosophy

2002-02-21 Thread dom
You've addressed the issue of someone submitting a form with altered fields to attack the server, and pointed out some more advantages, but I don't think you've addressed the issue of protecting the hidden cleartext data from others on the client side. True. But to tackle these concerns,

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread Hans Juergen von Lengerke
David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? Hans

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread David Harris
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? I just installed and played with CGI::SecureState (using the

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread Rob Nagler
Hans Juergen von Lengerke writes: Why not put everything in one field? Are there restrictions? Does it make a difference when using POST? That's what we do. There doesn't appear to be a restriction with POST. For while, we were encoding entire forms in URLs, but the limits got to us for

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread David Harris
Hans Juergen von Lengerke [mailto:[EMAIL PROTECTED]] wrote: David Harris [EMAIL PROTECTED] on Feb 19, 2002: The encoded information is [...] split into reasonable length hidden fields. Why not put everything in one field? Are there restrictions? Does it make a difference when using POST?

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread Perrin Harkins
When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread wsheldah
Sheldahl David Harris [EMAIL PROTECTED] on 02/20/2002 09:50:11 AM To: Perrin Harkins [EMAIL PROTECTED], Drew Taylor [EMAIL PROTECTED], mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: RE: [OT-ish] Session refresh philosophy Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread dom
The usual objection I've heard to using form fields is the security risk of people changing hidden fields in ways unforseen before submitting the form back, or of other people finding confidential data hidden in form fields if the user walks away and leaves their browser open, or the web

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread wsheldah
to verify more than once. Looks like it might worth be taking another look at this approach next time I start a new project. Wes [EMAIL PROTECTED] on 02/20/2002 11:48:28 AM Please respond to [EMAIL PROTECTED] To: mod_perl Mailing List [EMAIL PROTECTED] cc: Subject: Re: [OT-ish] Session

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread Drew Taylor
I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data structure. I prefer the simplicity of just

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread Rob Nagler
[EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more than once. It is always

Re: [OT-ish] Session refresh philosophy

2002-02-20 Thread ___cliff rayman___
Rob Nagler wrote: [EMAIL PROTECTED] writes: Looking at CGI::EncryptForm that Perrin mentioned, it appears that that module would address this concern by storing client-side in a single encrypted string that gets put in one hidden form variable. That also avoids having to verify more

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread David Harris
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: Okay, I only looked at it briefly and thought it stored the data on the client. Your module is actually more like CGI::EncryptForm I think, but yours may make things a bit more transparent. Maybe you should polish it up for CPAN. I looked

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread David Harris
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: I can see how your approach adds functionality by performing as expected if the user uses the Back button or opens the app. in more than one browser window. The usual objection I've heard to using form fields is the security risk of people

RE: [OT-ish] Session refresh philosophy

2002-02-20 Thread David Harris
Drew Taylor [mailto:[EMAIL PROTECTED]] wrote: I just looked at CGI::EncryptForm and David's module. The thing I like right off the bat about C:EF is that you pass a href to encrypt() and get back a href from decypt(). Perhaps I missed something, but FormContainer takes a string, not a data

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Ged Haywood
Hi there, On Mon, 18 Feb 2002, Milo Hyson wrote: maybe I'm just approaching the problem incorrectly. If one is doing a shopping-cart-style application (whereby someone selects/configures multiple items before they're ultimately committed to a database) how else would you do it? There has

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Drew Taylor
And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Perrin Harkins
And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form fields. It's primitive, but was actually a bit

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Drew Taylor
At 05:55 PM 2/19/2002 -0500, Perrin Harkins wrote: Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned a few days ago about storing state entirely inside a cookie with a message digest. The only difference is that by sticking it in a form element you're attaching it to a

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Milo Hyson
On Tuesday 19 February 2002 02:55 pm, Perrin Harkins wrote: Incidentally, this is mostly the same thing as what Jeffrey Baker mentioned a few days ago about storing state entirely inside a cookie with a message digest. The only difference is that by sticking it in a form element you're

RE: [OT-ish] Session refresh philosophy

2002-02-19 Thread David Harris
Drew Taylor [mailto:[EMAIL PROTECTED]]: And that is what I am doing for a small project I'm working on now. In my case, I'm not sure about the capabilities of the remote server, and I know for sure that I don't have a database available, so session information is saved via hidden form

RE: [OT-ish] Session refresh philosophy

2002-02-19 Thread David Harris
David Harris [[EMAIL PROTECTED]] wrote: [snip] I've attached some code. To use the code, you'll have to replace the module FreezeThawLite with Storable. Also, beware the \r\n newlines. (I pulled this out of CVS on my windows desktop.) I forgot to actually attach the code David

Re: [OT-ish] Session refresh philosophy

2002-02-19 Thread Perrin Harkins
I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. Sounds a lot like CGI::SecureState. Have you ever looked at it? - Perrin