>
> 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 conce
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 dat
[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 peop
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 looke
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
[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
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
worryi
m variable. That also
avoids having 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 PROTECTE
> 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
>
Wes 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]
> 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
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 us
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 rea
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
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
> 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
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
pac
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 fie
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 at
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
> 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 b
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 of
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
23 matches
Mail list logo
