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 worrying about a structure, and not having to worry about converting it to a string.
That said, I like the approach that the two modules use. One just goes an extra step to guarantee data security. While looking for full-time employment, I've been doing some freelance work, which basically is small CGI apps. C:EF looks like it would make my life much easier by ensuring consistent state w/ small effort on my part, and take care of any security precautions as well. Combine that w/ CGI::Application (after I add TT2 support :-) ), and my life as a freelance CGI guy just got a whole lot easier. Thank you to everyone who contributed to this thread. I've gotten all kinds of neat ideas I'll use in future projects! Drew At 10:19 AM 2/20/2002 -0500, Perrin Harkins wrote: > > 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 may make things a bit more transparent. Maybe you should polish it up >for CPAN. > >I'm well aware of the page-state vs. browser-state problem. I was recently >bitten by it again when some consultants built a web app for my company that >puts the search results in a session keyed on a cookie. As soon as the user >opens two windows, it's absolute mayhem. > >- Perrin Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! ***
