Set session expiration on case-by-case basis about django-social-auth

[omab]

That depends a lot on what you want to do and the case-by-case scenario.

[jacobg]

I just want to know how/where I specify login session expire parameters at
the time of login.

Thanks

On Mon, Apr 18, 2011 at 1:50 PM, omab <
[email protected]>wrote:

That depends a lot on what you want to do and the case-by-case scenario.

Reply to this email directly or view it on GitHub:
#52 (comment)

[omab]

Django-social-auth doesn't alter the session time on anyway, it only uses session as simple data storage, django contrib auth app does the same, it only stores a few things on session but doesn't change the live time. Instead this is left to default values.

Take a look to:
http://docs.djangoproject.com/en/dev/topics/http/sessions/?from=olddocs#session-cookie-age and
http://docs.djangoproject.com/en/dev/topics/http/sessions/?from=olddocs#session-expire-at-browser-close
to check django default values.

Currently I'm working on improvement to redirect URLs and it will support a custom URL for newly created users and for old users, maybe that view suites your needs to tweak the session times?

Matías

[jacobg]

Sorry for the delayed reply, I just got back from vacation. Thanks for the
info. I am trying out request.session.set_expiry() method to see if that
will suit my needs.

On a separate note, the social auth app doesn't seem to handle
changing/re-creating a UserSocialAuth object based on existing user object.
Instead, it creates a new user object. I modified the SocialAuthBackEnd to
handle this by:

1. in authenticate method, I changed UserSocialAuth.DoesNotExist exception
   handler to the following-

   except UserSocialAuth.DoesNotExist:
   
       user = kwargs.get('user')
   
       if user is None:  # new user
   
           if not getattr(settings, 'SOCIAL_AUTH_CREATE_USERS', True):
   
               return None
   
           username = self.username(details)
   
           email = details.get('email')
   
   
   
           # $JACOBGUR: Try to look up existing user object. Then we'll
   

   create

           # a new association
   
           from django.core.exceptions import ObjectDoesNotExist
   
           try:
   
               user = User.objects.get(username=username, email=email)
   
           except ObjectDoesNotExist:
   
           # END $JACOBGUR
   
               user = User.objects.create_user(username=username,
   

   email=email)

               is_new = True
   
       social_user = self.associate_auth(user, uid, response, details)
   

2. changed username method to the following:

   def username(self, details):

   """Return an unique username, if SOCIAL_AUTH_FORCE_RANDOM_USERNAME
   
   setting is True, then username will be a random 30 chars md5 hash
   
   """
   
   def get_random_username():
   
       """Return hash from random string cut at 30 chars"""
   
       return md5_constructor(urandom(10)).hexdigest()[:30]
   
   
   if getattr(settings, 'SOCIAL_AUTH_FORCE_RANDOM_USERNAME', False):
   
       username = get_random_username()
   
   # $JACOBGUR: Add SOCIAL_AUTH_EMAIL_USERNAME setting and condition
   
   elif getattr(settings, 'SOCIAL_AUTH_EMAIL_USERNAME', False):
   
       username = details['email']
   
   # END $JACOBGUR
   
   elif USERNAME in details:
   
       username = details[USERNAME]
   
   elif hasattr(settings, 'SOCIAL_AUTH_DEFAULT_USERNAME'):
   
       username = settings.SOCIAL_AUTH_DEFAULT_USERNAME
   
       if callable(username):
   
           username = username()
   
   if not username:
   
       username = get_random_username()
   
   
      # $JACOBGUR: Remove the following commented-out code that
   

   prevents user object

   # from already existing
   
   '''fixer = getattr(settings, 'SOCIAL_AUTH_USERNAME_FIXER', lambda u:
   

   u)

   name, idx = username, 2
   
   while True:
   
       try:
   
           name = fixer(name)
   
           User.objects.get(username=name)
   
           name = username + str(idx)
   
           idx += 1
   
       except User.DoesNotExist:
   
           username = name
   
           break'''
   
      # END $JACOBGUR
   
   
   return username
   

Is this type of functionality something you are interested to integrate in
your app?

On Mon, Apr 18, 2011 at 5:26 PM, omab <
[email protected]>wrote:

Django-social-auth doesn't alter the session time on anyway, it only uses
session as simple data storage, django contrib auth app does the same, it
only stores a few things on session but doesn't change the live time.
Instead this is left to default values.

Take a look to:

http://docs.djangoproject.com/en/dev/topics/http/sessions/?from=olddocs#session-cookie-ageand

http://docs.djangoproject.com/en/dev/topics/http/sessions/?from=olddocs#session-expire-at-browser-close
to check django default values.

Currently I'm working on improvement to redirect URLs and it will support a
custom URL for newly created users and for old users, maybe that view suites
your needs to tweak the session times?

Matas

Reply to this email directly or view it on GitHub:
#52 (comment)

[omab]

Actually it does, check the account association feature. Once the user is logged in in your system (old or new), it should be able to associate other social accounts.

[jacobg]

Thanks.

Is the account association feature implicit?

I am running into a problem now, b/c I am accessing my site through two
different hostnames. As a result, Google returns a different open id for my
username, and then two UserSocialAuth objects get created. Then I end up
with this error:

MultipleObjectsReturned at /complete/google/

get() returned more than one UserSocialAuth -- it returned 2! Lookup
parameters were {'provider': 'google'}

Do I need to do something explicit to support two or more UserSocialAuth
objects for a particular user?

On Wed, Apr 27, 2011 at 10:26 AM, omab <
[email protected]>wrote:

Actually it does, check the account association feature. Once the user is
logged in in your system (old or new), it should be able to associate other
social accounts.

Reply to this email directly or view it on GitHub:
#52 (comment)

[omab]

What do you mean with implicit? The user must be logged in to use the association feature. If you check the demo, you will that the association links are given in the second page when the user has authenticated.

[jacobg]

I do see that the demo support multiple associations of different providers to one user. What about multiple associations of the same provider to one user? For example, in the scenario of my last post on this thread, where a user logs into the web site using different server hostnames?

[omab]

That's also supported because the only restriction is same UID where a UID is a unique identifier provided by the authentication provider for such account, so it will be different for different accounts.

[jacobg]

Hmm, I'm not seeing a query on UID. At:
File "/Users/jacobgur/Documents/workspace/djangotimeclock/src/social_auth/views.py", line 51, in complete_process
social_user = user.social_auth.get(provider=backend_name)

it looks up UserSocialAuth object by user and provider values, but not by uid. If the same user on same provider accesses provider (say, Google) via a different consumer hostname (e.g., foomail.com, mail.foo.com) then UID will be different and thusly you should see the following error:
MultipleObjectsReturned: get() returned more than one UserSocialAuth -- it returned 2! Lookup parameters were {'provider': 'google'}

[omab]

Yeah, you are right there, the code is not compatible, I'll make a fix for it ASAP.

[jacobg]

Thank you!

On Tue, May 3, 2011 at 5:57 PM, omab <
[email protected]>wrote:

Yeah, you are right there, the code is not compatible, I'll make a fix for
it ASAP.

Reply to this email directly or view it on GitHub:
#52 (comment)