http://groups.google.com/group/webpy/browse_thread/thread/2f...
If he couldn't spot that when he posted, I don't trust him to spot any other problems with web.py
Then it hit me.
He was suggesting you give the pickled object back to the client in the session cookie and load whatever the client sends later right back into the interpreter. Whee!
I've done that with signed cookies.
Think HMAC, though I used two completely different keys, rather than generating them from one key, added an optional step of appending the client's IP address after the first hashing (with the first key) and before the second one.
(The second hashing in HMAC is designed to prevent collision attacks (even on weak algorithms like MD5), since you'd essentially have to find a fraudulent input that collides twice: once when hashed, and once more when its hash is hashed).
My implementation also allowed the data to span an arbitrary number of ~4kb cookies). Firefox maxed out at around 0.5MB, though if you're using that much session data, you may want to rethink your app design... ;)
I am not sure it is by laziness, or it is purposely done to scare n00bs away from it.
It's a pitty when somebody takes the time to built a decent and useful framework, but just hinders its adoption, by not going the extra mile and providing good documentation.
My only cons (last I checked):
- Connecting to multiple databases is kind of a hack.
- Depreciation of cheetah over aaron's templating system.
So, it's just about perfect for me.
PROS: * Light and fast, * Really flexible, * Really easy to learn, * Easy to install, * Nice error reports (mostly copied from Django), * No database ORM
CONS: * No database ORM, just some helper functions: insert(...), update(...), select(...), etc. You must also build the DB tables by yourself. * Limited documentation.