Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_user_details() vs user_data() #7

Closed
gsakkis opened this issue May 17, 2013 · 4 comments
Closed

get_user_details() vs user_data() #7

gsakkis opened this issue May 17, 2013 · 4 comments

Comments

@gsakkis
Copy link
Contributor

gsakkis commented May 17, 2013

I'm about to add a new social backend and I'm not sure what's the difference between the get_user_details() and user_data() methods. In this particular backend, the response from the ACCESS_TOKEN_URL has almost no user details other than the token itself; all details are fetched from a separate api call to the service. So I tried returning an empty dict from get_user_details() but apparently the username is autogenerated in this case, which is not what I want. I can make the api call to the service to retrieve the user data in get_user_details() but then what's the point of having user_data()?

Thanks,
George

@omab
Copy link
Owner

omab commented May 17, 2013

@gsakkis, get_user_details() should be defined on the backend that works with django-auth mechanism, while user_data() belongs to the authentication class used by DSA. In your case user_data() should call that service and retrieve the needed user information, then on get_user_details() you should transform that data into the expected format for DSA which is:

{
    'username': <username if any>,
    'email': <user email if any>,
    'fullname': <user full name if any>,
    'first_name': <user first name if any>,
    'last_name': <user last name if any>
}

@gsakkis
Copy link
Contributor Author

gsakkis commented May 17, 2013

Ah, so the response parameter of get_user_details() is the result of user_data(); I thought they were called in the opposite order.

Pull request coming soon, thanks!

@omab
Copy link
Owner

omab commented May 17, 2013

@gsakkis, when I wrote my previous reply I thought I was on django-social-auth project, not python-social-auth, it still applies (kinda), so let me rewrite it.

user_data() should call the service that provide the extra user information, then get_user_details() must transform it to into the format that PSA expect, which is:

{
    'username': <username if any>,
    'email': <user email if any>,
    'fullname': <user full name if any>,
    'first_name': <user first name if any>,
    'last_name': <user last name if any>
}

@omab
Copy link
Owner

omab commented May 17, 2013

I think we can close this one.

@omab omab closed this as completed May 17, 2013
jenkins-ks pushed a commit to nttks/python-social-auth that referenced this issue Mar 30, 2016
jenkins-ks pushed a commit to nttks/python-social-auth that referenced this issue Aug 5, 2016
…d-slugify

Fix slugify for PY2 str omab#6
(cherry picked from commit a0c7af8)
jenkins-ks pushed a commit to nttks/python-social-auth that referenced this issue Aug 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants