Hi Ben, I'm not storing anything else in cookie sessions, just the default Devise login vals which it handles, not specified by me. And it works perfectly for a single login in the same browser. It only throws a glitch if I try to login as customer AND admin in the same browser, hence storing in the same cookie. Single model login in same browser/cookie v smooth. Multi same browser/cookie = problemo.
googling this, it seems the cookie 4k overflow is a common problem with Devise with almost everyone suggesting using a different store such as db or memcache as the solution. I just felt hitting the db again and again to authenticate pages based on login prob not ideal. At this point I'm trying out Sorcery but I still have Devise installed so let me see if I can do an inspect on the cookie to see the specific vars and data stored. Also I just realized if I change session store to db, then I can't store just customer_id or admin_id in a cookie. When I looked at what was in the cookie before, it was about 8 objects approx, not too big either. Devise is working really smooth except for logging in a second time on a different model in the same browser (same cookie). That wouldn't happen typically in production so maybe a non issue, but it throws you off seeing an overflow while testing. What are you using for authentication in your apps, Devise or another gem? Thanks for your feedback. On Sunday, April 6, 2014 12:50:35 PM UTC-7, Benjamin Wanicur wrote: > > Hi Dude and Chris > > Chris, it’s worth noting that he is exceed his 4k *cookie* storage limit, > not session limit. I second Chris’ question about "what are you storing in > the cookie ?” . Without seeing any code, I’m just guessing, but typically > you should only store light weight stuff in the cookie. It’s been awhile > since I’ve set up Devise, but in general, you should usually just store > unique keys that point to values in the session (or other data store) in > your cookie. You should also not store anything sensitive in the cookie. > I’ve used Devise with multiple users logged in at the same time (admin and > reg user) without problems. Maybe you can show us some code ? Apologies > in advance if I am misinterpreting your problem. > > Cheers > > Ben W > > On April 6, 2014 at 11:53:41 AM, Abiding Dude ([email protected]<javascript:>) > wrote: > > Hi Chris, a number of Stack Overflow answers to Devise > ActionDispatch::Cookies::CookieOverflow mentioned the 4k cookie limit > problem with the recommended solution being to use a different store. > > https://coderwall.com/p/dqdyig > > At this point in testing I'm not storing anything else in session, the 4k > limit seems to be exceeded when I login as a customer AND as admin using > Devise. Logging into just 1 works perfectly fine, its the second login > adding to the cookie that appears to cause the overflow. > > I'm not using memcache at the moment and felt hitting the db may not be > ideal for performance. Once you login with Devise with session stored in > db, will it hit the db every time to verify access to a page or could that > be handled by having just the user_id in a cookie session. > > So on login store session info in db, set only the user_id in cookie > session and use only that value to enable access to various pages or > sections. > > I wired up auth from one of the wire it yourself railscasts, it works fine > but not ideal for forgot password. Devise is powerful and pretty user > friendly cept for this cookie overflow issue. I checked Sorcery v briefly > yesterday but per your suggestion will revisit in more detail this > afternoon. Thanks for the tip not to wire it myself. > > On Sunday, April 6, 2014 9:10:25 AM UTC-7, Chris McCann wrote: >> >> There are other options for authentication in Rails. Depending on your >> needs, Sorcery is a fairly well-written, lighter weight alternative to >> Devise: >> >> https://github.com/NoamB/sorcery >> >> I, along with most other experienced Rails developers here, would >> strongly discourage writing your own authentication solution. There's no >> need to reinvent something so critical to an app as authentication when >> there is battle-tested, community-vetted code already available. >> >> The bigger question here, though, is why you're getting the cookie >> overflow error. Does this Stack Overflow post describe your situation? >> >> http://stackoverflow.com/questions/7117200/devise-for-twitter-cookie-overflow-error >> >> You should take a close look at what you're storing in the cookie-based >> session, in addition to what Devise is stashing there. >> >> If you find for some reason that you have to put more than 4k of data in >> the session then a database or memcached session store would certainly >> allow that. Is there a particular reason why neither of these session >> stores is an option? >> >> Cheers, >> >> Chris >> >> On Sunday, April 6, 2014 1:25:49 AM UTC-7, Abiding Dude wrote: >>> >>> Am building an ecommerce app and finding a problem with overflow on >>> cookies if I have 2 models with Devise. >>> >>> The suggested solution via stack overflow is to use the db to get around >>> this issue which I'd rather not, or memcache. >>> >>> Is there any other solution recommended for authentication? Or maybe >>> write my own? >>> >>> There's customer login, affiliate login and admin login. Neither will >>> login on same browser at same time, but the overflow issue seems to be >>> common in exceeding the 4k limit once you do 2 logins using cookies with >>> Devise. Other than that its been a very user friendly and quite powerful >>> gem. Thanks for any pointers. >>> >> -- > -- > SD Ruby mailing list > [email protected] <javascript:> > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups > "SD Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
