5 ms·

I personally like web.py: PROS: * Light and fast, * Really flexible, * Really easy to learn, * Easy to install, * Nice error reports (mostly copied from Django

I personally like web.py: 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.

inklesspen 19y ago
I stopped using web.py after I had to correct Aaron when he recommended a 'session' implementation that had a massive gaping security hole. http://groups.google.com/group/webpy/browse_thread/thread/2fcbcb60a99a1c79/4d2a53b33adc3cdb?#4d2a53b33adc3cdb 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
- bayareaguy 19y ago
  For a second I didn't get what the big deal was here. Sure you have to keep your pickled python objects in a secure place on your server. Sure you could have problems if someone could get at those, but they would need to crack your server first and then figure out how your app worked. If they could do that you're hosed anyway... 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!
  - icky 19y ago
    > 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.
    - inklesspen 19y ago
      There wasn't any encryption involved in his suggestion. :D
    - bayareaguy 19y ago
      I imagine you didn't store any per-session state on the server as well, so I'm curious about what you used to validate the cookie.
      - icky 19y ago
        I secretly salted the cookie. 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... ;)
- juanpablo 19y ago
  He is doing a good job so far. Anyway, I believe he isn't the only developer of web.py anymore.
venturebatman 19y ago
hi how can i reach u?
- tim2 19y ago
  I can help. See profile.
irrelative 19y ago
Seconded. It's not really a framework as much as a url mapper. Plus, it's quite small so if you're having trouble understanding something, the source is available.
tim2 19y ago
I am quite against database ORM, so that's no con for me. Documentation isn't great either but things are generally very easy to figure out. 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.
ardit33 19y ago
Limited Documentation = really almost non-existent, except few samples, and few lines here and there in their website. 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.

inklesspen 19y ago

I stopped using web.py after I had to correct Aaron when he recommended a 'session' implementation that had a massive gaping security hole. http://groups.google.com/group/webpy/browse_thread/thread/2fcbcb60a99a1c79/4d2a53b33adc3cdb?#4d2a53b33adc3cdb 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

bayareaguy 19y ago
For a second I didn't get what the big deal was here. Sure you have to keep your pickled python objects in a secure place on your server. Sure you could have problems if someone could get at those, but they would need to crack your server first and then figure out how your app worked. If they could do that you're hosed anyway... 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!
- icky 19y ago
  > 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.
  - inklesspen 19y ago
    There wasn't any encryption involved in his suggestion. :D
  - bayareaguy 19y ago
    I imagine you didn't store any per-session state on the server as well, so I'm curious about what you used to validate the cookie.
    - icky 19y ago
      I secretly salted the cookie. 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... ;)
juanpablo 19y ago
He is doing a good job so far. Anyway, I believe he isn't the only developer of web.py anymore.

venturebatman 19y ago

hi how can i reach u?

tim2 19y ago
I can help. See profile.

irrelative 19y ago

Seconded. It's not really a framework as much as a url mapper. Plus, it's quite small so if you're having trouble understanding something, the source is available.

tim2 19y ago

I am quite against database ORM, so that's no con for me. Documentation isn't great either but things are generally very easy to figure out. 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.

ardit33 19y ago

Limited Documentation = really almost non-existent, except few samples, and few lines here and there in their website. 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.