OK, right now I'm looking at replacing SessionMiddleware with a subclass that will take a dict with multiple session cookie names and timeout values, and set both the traditional request.session from the default values from settings (so as not to mess up third-party apps that depend on it) and a custom request.sessions list with all sessions.
Does anyone see any major pitfalls to this approach? Thanks, -Nan On Nov 4, 2:32 pm, Nan <ringe...@gmail.com> wrote: > OK, the subject doesn't *quite* describe what I need to do, but > almost. Basically, I'd like to have > > 1) one "session" that expires after logout or browser close, and > applies to logged-in sessions (like the default Django session > framework using the "SESSION_EXPIRE_AT_BROWSER_CLOSE" setting) > > 2) one "session" that's persistent indefinitely and applies to both > anonymous and logged-in users. > > The data in (2) could probably be stored directly in a cookie, but > it's pretty handy how the session framework protects one from users > editing cookies, abstracts away database storage, etc. -- and I'd > rather not have to duplicate this functionality. > > Any suggestions? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
