I've been in contact with Heroku's support regarding this issue, and here is what they told me :
This doesn't appear to be a problem coming from our platform. Any request > coming into your app will have session cookies passed. > The way sessions stored on databases work is by setting a cookie with an > id, and then looking for the session data related to that id. I checked into my browser's development tools to check cookies and found that indeed, there are two cookies : session_id_APPNAME and session_id_admin. These cookies and their values are persistent through requests, even with multiple dynos. I now wonder about web2py's session management and especially regarding Auth : *How exactly does it decide wether a user is an existing user or a new user ?* If it works as this person from Heroku support described, then it weird because my database has exactly ONE entry in the table "web2py_session_APPNAME" and that is exactly the value of the cookie in found in my browser. On Wednesday, October 29, 2014 5:59:05 PM UTC+1, Louis Amon wrote: > > I tried to apply Derek’s advice by storing sessions in cookies, same > problem : as long as my web app runs on 1 dyno everything works fine but if > I scale it to 2 or more then sessions start to break. > > I also +1 on what Anthony said : wether it be stored in a database or in a > cookie, a session should be consistent no matter how much you scale your > system. This issue is really weird (and annoying). > > If you guys you like to replicate here’s how : > > > 1. Deploy any app to Heroku using web2py’s Rocket web server > 2. Scale your Heroku app to 2 or more (you don’t have to register a > means of payment to do it) > 3. Go to yourapp.com/appadmin > 4. Navigate through appadmin (at least 5-10 requests) > 5. You will notice that you get randomly disconnected, and have to > enter your password multiple times > > > > Le 28 oct. 2014 à 23:39, Derek <sp1d...@gmail.com> a écrit : > > Store your sessions in cookies? > > To *store sessions in cookies* instead you can do: > > session.connect(request,response,cookie_key='yoursecret',compression_level=None) > > Here cookie_key is a symmetric encryption key. compression_level is an > optional zlib encryption level. > > While sessions in cookie are often recommended for scalability reason they > are limited in size. Large sessions will result in broken cookies. > > > > On Friday, October 24, 2014 2:41:06 AM UTC-7, Louis Amon wrote: >> >> I am trying to scale up my application deployed on Heroku by increasing >> the number of dynos and am currently confronted with the issue of handling >> sessions in a distributed environment. >> >> The regular solution (storing sessions in the database) does not seem to >> work anymore when multiple dynos run concurrently : clients get asked for >> login at every request. >> I have no idea why this doesn't work since databases are supposed to be >> shared between dynos on Heroku, but as far as I know there are 2 possible >> ways to manage scalable sticky sessions: >> >> >> 1. Memcache : couldn't use gluon/contrib to test this because the >> MemcacheClient does not allow authentication in a connection string (i.e. >> services like Memcached, MemCachier...) >> 2. Redis : same issue --> Redis client does not seem to work well >> with auth-based services that are available on Heroku (e.g. RedisCloud) >> >> >> >> Any idea why db-based sessions do not stick out of the box on Heroku, >> and/or how to use a Cloud-based service to achieve session stickiness ? >> > > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to a topic in the > Google Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/aRIVySTv6hE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
