Open andrew-azarov opened 10 years ago
Hi Andrew,
I m not ok with your proposition. Bottle should stay a simple and lightweight MICRO web-framework. More we add extra functionalities inside bottle.py, more we should create bugs. Bottle must work simply and fastly for his primary job : being a basic web-framework.
As defnull say here http://bottlepy.org/docs/dev/recipes.html#keeping-track-of-sessions << There is no built-in support for sessions because there is no right way to do it (in a micro framework).
If you would like a session manager, you can create one as a Github project, and use it in couple with Bottle. If some people are interested by your project, they should contribute too :)
Beaker is not so bad, and if you find bugs inside it, you can create issues in Github here : https://github.com/bbangert/beaker/issues
Peace and Love.
Message du 22/02/14 14:08 De : "Andrew Azarov" A : "defnull/bottle" Copie à : Objet : [bottle] Native Session support (#591)
As beaker is no longer maintained there might be a need for native session support with files. This can be made in one class which should not take a lot of space in the module. I can supply a not so working one (had problems with concurrency when using gevent for example)... This is only feature which should be in bottle as currently it requires a dance with the wolves to set up correctly and beaker is still buggy as hell. — Reply to this email directly or view it on GitHub.
It still would be microframework. Problem is session support is a must have for interactive applications - and that's what bottle is for, isn't it? Basic auth can go as far as you don't need to logout...
"As beaker is no longer maintained" huh? Did I miss something?
+1. Why not support sessions through a plugin? I don't see a strong case for putting it into the core.
On Sat, Feb 22, 2014 at 1:01 PM, xxbillouxx notifications@github.comwrote:
Hi Andrew,
I m not ok with your proposition. Bottle should stay a simple and lightweight MICRO web-framework. More we add extra functionalities inside bottle.py, more we should create bugs. Bottle must work simply and fastly for his primary job : being a basic web-framework.
As defnull say here http://bottlepy.org/docs/dev/recipes.html#keeping-track-of-sessions << There is no built-in support for sessions because there is no right way to do it (in a micro framework).
If you would like a session manager, you can create one as a Github project, and use it in couple with Bottle. If some people are interested by your project, they should contribute too :)
Beaker is not so bad, and if you find bugs inside it, you can create issues in Github here : https://github.com/bbangert/beaker/issues
Peace and Love.
Message du 22/02/14 14:08 De : "Andrew Azarov" A : "defnull/bottle" Copie à : Objet : [bottle] Native Session support (#591)
As beaker is no longer maintained there might be a need for native session support with files. This can be made in one class which should not take a lot of space in the module. I can supply a not so working one (had problems with concurrency when using gevent for example)... This is only feature which should be in bottle as currently it requires a dance with the wolves to set up correctly and beaker is still buggy as
hell.
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/defnull/bottle/issues/591#issuecomment-35809360 .
Hi Andrew :)
if you find some "bugs" in beaker, maybe you can try to submit your issues in the beaker github project ;)
+1 for a plugin (isn't there a plugin already? I still don't see whats wrong with the middleware)
@defnull there has been no commits in 5 months: https://github.com/bbangert/beaker/commits/master - and the number of bugs is increasing. Some bugs are blockers for Python 3 unfortunately.
+1 to plugin :D
Flask has a relatively simple implementation based on signed cookies only that could be used as an example: https://github.com/mitsuhiko/flask/blob/master/flask/sessions.py
make bottle-beaker, start now in https://github.com/avelino/bottle-beaker
@defnull best inside the bottle organization?
@FedericoCeratto Bottle has signed cookies, too. We just don't call it "session". @avelino bottlepy/bottle-beaker
Writing basic beaker and send push to https://github.com/bottlepy/bottle-beaker
send to pypi new version: https://pypi.python.org/pypi/bottle-beaker
@defnull add you in pypi!
@defnull: usually sessions provide a small key-value storage (with multiple keys) and are tamper-resistant.
Speaking of which, cookie-stealing attacks would allow the attacker to read the content of Bottle-generated cookies and access potentially sensitive data (e.g. login name, domain...). Should the cookie be encrypted as well (e.g. encrypt-than-mac)?
Also, cookies are decoded by doing unpickling. If an attacker is able to obtain the server signing key it can perform arbitrary code execution: http://v0ids3curity.blogspot.ie/2012/10/exploit-exercise-python-pickles.html
Cookie-based sessions in Beaker perform encryption (with nonces) and signing: https://github.com/bbangert/beaker/blob/master/beaker/session.py
For reference: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
Related to #447 and #448 - Possibly unsafe use of pickle()
I don't think bringing it into bottle is the right answer, but the example using beaker's session should definitely be removed or replaced. We got hit hard with it's race conditions last year, and wound up rolling our own replacement: https://github.com/keredson/drsession
Yes, beaker is not perfect. But I do not known any alternative that really solves this issue other than not using sessions and store stuff in a real database instead. Even 'drsession' shows the same race condition problem if you modify the same key in a session from two concurrent requests. For example, you would not be able implement a request counter (for rate limiting) with drsession in any reliable way. You'd have to access redis directly for that (using the redis HINCRBY
command) or risk loosing updates occasionally.
I think it would not hurt to warn users about these limitations, and make absolutely clear that sessions are no substitute for a real database. If it's not acceptable to loose updates, don't put it in a session.
But for simple use cases, beaker and co are still useful. A typical workflow (store user info in session on login, remove session on logout) works just fine. I think its an error to use sessions for more than that.
Didn't see this reply before I responded to other issue, sorry. Actually pretty sure we implemented hincrby
for +=
, but regardless, you're conflating a race condition for a single key with a race condition for any key.
I don't agree that it's an error to use sessions for more than the session id. If that was the intent, why support a dictionary like interface? Why not have it just be an object with nothing but an id
attribute and a destroy()
function. You can't give people a car and when they complain the brakes don't work tell them "well it's really not designed to be driven, just as a lawn ornament".
But whatever, I've said my peace. :)
@defnull you were right, we weren't using HINCRBY
. Fixed. https://github.com/keredson/drsession/issues/3
As beaker is no longer maintained there might be a need for native session support with files.
This can be made in one class which should not take a lot of space in the module. I can supply a not so working one (had problems with concurrency when using gevent for example)... This is only feature which should be in bottle as currently it requires a dance with the wolves to set up correctly and beaker is still buggy as hell.