Code

Opened 9 years ago

Closed 7 years ago

Last modified 2 years ago

#1 closed enhancement (fixed)

Create architecture for anonymous sessions

Reported by: adrian Owned by: jacob
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

We need an architecture for anonymous sessions. Right now we have django.models.auth.sessions, but that only handles registered users' sessions. We need a system that automatically creates and manages sessions for anonymous users.

Here's one idea for this:

  • In the settings file, you define a SESSION_MODULE string, like the AUTH_PROFILE_MODULE, which points to the model to use for sessions.
  • Using this, httpwrappers automatically creates a request.session object which is persistant across requests based on cookies, etc.

Attachments (0)

Change History (14)

comment:1 Changed 9 years ago by Ksenia

WSGI session middleware can also be used for this (when WSGI support will be available :)

comment:2 Changed 9 years ago by maurycy

Besides lack of the anonymous sessions, which is described in the first ticket,
we have together two problems with the sessions. The second is demand to
reimplement sessions code as often as we need to merge them with other model,
like django.models.auth.sessions.

If I understand correctly, the current adrian's idea assumes creating the
global session model for every anonymous client, made through httpwrappers.
I see a few potential limitations. One, it seriously reduces flexibility
of the sessions. With the constant declared keys, we cannot add an another
during work. Two, modifing httpwrapers on our every whin certainly won't
increase quality of the code.

My proposals are a bit different.

Generally, idea of making the sessions the models is good, but their
flexibility should be built-in and enforced. Users should not design
them. Writing the not tested Python, pseudo code:

class Session(meta.Model):
  fields = (
    meta.CharField('session_md5', 'session MD5 hash', maxlength=32),
    meta.DateTimeField('start_time', 'start time', auto_now=True),
    meta.DateTimeField('time_to_live', 'time_to_live')
  )

class Field(meta.Model):
  fields = (
    meta.ForeignKey(Session),
    meta.CharField('key', 'key of the field', maxlenght=64),
    meta.TextField('value', 'value of the field', maxlength=64),
  )

Now, we're not limited with the declared fields. We can extend the base
model no matter how.

Then, working with the sessions would looks like:

import django.models.products import products
import django.models.sessions import sessions

def test(request):
    try:
        session = sessions.Session(name='just_a_test')
    expect sessions.SessionDoesNotExist:
        return HttpResponseRedirect('not/logged')

    session.add_field(key='rocco', value='rocco is the best')
    session.save()

As careful readers would point, there's no playing with the cookies and
setting the time to live. It should be obviously done after creationg of the
object. At the moment, I don't have idea how to make it, but I don't think
it'll be the problem to add some kind of _post_creation() method.

The httpwrappers accusation is easier to respond. The middleware has been
invented for this kind of challenges. Anonymous session can be then created
automatically after every request by our new middleware class, which would
take care on them. If you don't need anonymous sessions, you simply do not set
MIDDLEWARE_CLASSES.

Feel free to comment.

comment:3 Changed 9 years ago by mmarshall

From my limited knowledge and experience, it looks good. Although, the first thing I would do would be to subclass sessions.Session to support something like """ sessionrocco?='rocco is the best!' """ ;-)

MWM

comment:4 Changed 9 years ago by james

well the one true thing that I need in django is handling session, i mean storing in session form objects, passwords and other stuff, i wish you everything good.

comment:5 Changed 9 years ago by jacob

  • milestone set to Version 1.0
  • Owner changed from adrian to jacob
  • Status changed from new to assigned

comment:6 Changed 9 years ago by Manuzhai

Hmm, I think it should be possible to do session.field = value, which may preclude session from being a normal meta.Model descendent. That would be alright, though - it *is* special, after all. And I think there should be ways to set TTL and other stuff like that.

comment:7 Changed 9 years ago by anonymous

  • Cc frido.ferdinand@… added

comment:8 Changed 9 years ago by adrian

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [518]) Fixed #1 -- Added anonymous session support via middleware and request.session. Removed the former request.session, which wasn't being used anyway. Removed auth.Session model. See the BackwardsIncompatibleChanges wiki page for IMPORTANT notes on code you'll have to change and a DB table you'll have to create.

comment:9 Changed 7 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

comment:10 Changed 7 years ago by jacob

(In [4462]) Trivial whitespace chance to AUTHORS to test the trac commit hook. Refs #1 also for testing, but it doesn't really.

comment:11 Changed 7 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

Testing reopen - ignore, please...

comment:12 Changed 7 years ago by jacob

  • Resolution set to fixed
  • Status changed from reopened to closed

Refixing; looks like it works.

comment:13 Changed 3 years ago by anonymous

Test - ignore (JKM).

comment:14 Changed 2 years ago by frido.ferdinand@…

  • Cc frido.ferdinand@… removed
  • Easy pickings unset
  • UI/UX unset

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.