The point is... why use cookies al all when there is an app-level session? If you use cookies it may be because you want to do something that canot be done with sessions. Adding a prefix would get in the way of some possible uses.
On Thursday, 9 August 2012 10:40:01 UTC-5, Yarin wrote: > > To me a default where apps share cookies doesn't seem out of with line > with the other things apps share- the default logger for example. Just as > making an app-specific logger can be achieved by passing > request.application to a new instance, so we can prefix app-specific > cookies with the app name. To me it's the more obvious default. Interested > to hear what others think. > > On Thursday, August 9, 2012 12:27:29 AM UTC-4, Massimo Di Pierro wrote: >> >> if we default path = '/' then all apps share cookies and that may be a >> problem. >> >> expiration is also not set. They are Cookies.SimpleCookie() objects. >> >> On Wednesday, 8 August 2012 22:14:25 UTC-5, Yarin wrote: >>> >>> Got it- added the path and everything's working now. >>> >>> I was not aware cookies are path dependent- I thought they were >>> restricted only by domains/sub-domains. Maybe I'm the only one, but my >>> guess would be that a lot of people are operating under that assumption. >>> For that reason my vote would be to either make the default the root path >>> or at the very least to make clear in the documentation what the default >>> behavior is now. I punched the wall a few times this afternoon trying to >>> understand why my cookies wouldn't persist on the same function call from >>> one request to another, and the whole time was barking up the wrong trees. >>> >>> Also, what's the default expiration value for cookies? >>> >>> On Wednesday, August 8, 2012 9:35:04 PM UTC-4, Massimo Di Pierro wrote: >>>> >>>> I can reproduce your behavior. The problem is that when you set >>>> >>>> response.cookies['LAST_FUNCTION'] = request.function >>>> >>>> you are not setting a path >>>> >>>> response.cookies['LAST_FUNCTION']['path']='/myapplication' >>>> >>>> therefore the browser assumes the scope of the cookie is the URL. >>>> >>>> web2py cannot set the path (scope) automatically because it does not >>>> know how your application is exposed. For example: >>>> >>>> response.cookies['LAST_FUNCTION']['path']='/'+request.application >>>> >>>> would behave differently depending on the routes. >>>> I would not be tremendously opposed to changing this default but I am >>>> not convinced there is a better default. >>>> >>>> >>>> >>>> >>>> On Wednesday, 8 August 2012 18:25:36 UTC-5, Yarin wrote: >>>>> >>>>> This is a weird issue turned weirder, but I've at least been able to >>>>> reproduce it: >>>>> >>>>> *Controller:* >>>>> >>>>> def func_a(): >>>>> >>>>> response.cookies['LAST_FUNCTION'] = request.function >>>>> return str(request.cookies) >>>>> >>>>> def func_b(): >>>>> >>>>> response.cookies['LAST_FUNCTION'] = request.function >>>>> return str(request.cookies) >>>>> >>>>> >>>>> def dump_cookies(): >>>>> >>>>> return str(request.cookies) >>>>> >>>>> >>>>> >>>>> Make 5 calls in succession: >>>>> /func_a >>>>> /func_b (LAST_FUNCTION = 'func_a') >>>>> /func_a (LAST_FUNCTION = 'func_b') >>>>> /func_b (LAST_FUNCTION = 'func_a') >>>>> /dump_cookies (LAST_FUNCTION = 'func_b') >>>>> >>>>> Everything checks out. >>>>> >>>>> Now clear cookies, and try the calls again, but this time with >>>>> different args for each: >>>>> /func_a/1 >>>>> /func_b/2 >>>>> /func_a/1 (LAST_FUNCTION = 'func_a') >>>>> /func_b/2 (LAST_FUNCTION = 'func_b') >>>>> /dump_cookies -No LAST_FUNCTION cookie- >>>>> >>>>> In other words, the cookies are no longer being shared across >>>>> functions! >>>>> >>>>> Please try this yourself and report back. If anyone can make sense of >>>>> this, I want to hear it... >>>>> >>>>> --
