Submitting Pull Requests

This pull request adding Apple provider to allauth package PR has a breaking change now — update to store Apple config in the SocialApp model

General

• [x] Make sure you use semantic commit messages.
• [x] All Python code must be 100% pep8 and isort clean.
• [x] JavaScript code should adhere to StandardJS.
• [x] If your changes are significant, please update ChangeLog.rst.
• [x] Feel free to add yourself to AUTHORS.

Provider Specifics

In case you add a new provider:

• [x] Make sure unit tests are available.
• [x] Add an entry of your provider in test_settings.py::INSTALLED_APPS and docs/installation.rst::INSTALLED_APPS.
• [x] Add documentation to docs/providers.rst.
• [x] Add an entry to the list of supported providers over at docs/overview.rst.

Hi, i've been using django-allauth for a rest api, it works very good but i found that this use case has a problem: the email being sent contains an url to the api itself instead of the front end. This was solvable via subclassing, of course, but i thought it would be nice to have it supported inside the module.

A user whose account has been deactivated can use the reset password form to log in. They have to update their password every time, but they can get in that way.

Presumably filter_users_by_email() should exclude inactive users. Or it might need to be an additional filter in ResetPasswordForm.clean_email() depending on how widespread filter_users_by_email() is used. I'm on an older version, but the current version doesn't fix it.

Alrighty, now that 8dc2f2d5cc3ce0e5e1b999129ceaa57ed4e75390 has landed I can go ahead with this :)

The first commit starts addressing #1442. It doesn't outright remove the adapter but it makes it way less nasty. The current adapter always causes the "user", "user1"... mechanism because the battletag is never saved. Additionally, the current adapter always forces at least two sql writes (first the user, then re-saves the user's battletag).

So we first allow overriding the username_regex attribute. Rather than make it a setting, we allow specifying it in the adapter, which I believe to be a reasonable solution. With that done, we can change the Battle.net adapter to use that and get the battletag as the username data.

The next commits address the china issue:

• valid_region is simply a list of the valid region inputs for battlenet_region
• Appending -cn to the UIDs matching cn region is required because the UIDs can clash between US and China; if we don't do that, an account in china can take over an account in the US if running both on the same server.
• Finally, the last commit allows overriding the region in /account/battlenet/login/ by specifying, for example, ?region=cn. I'm not sure if there is existing functionality for this but I think it's acceptable.

After making this question in StackOverflow, I've just discovered this comment in the source code helpers.py file:

            if account_settings.UNIQUE_EMAIL:
                if email_address_exists(email):
                    # Oops, another user already has this address.  We
                    # cannot simply connect this social account to the
                    # existing user. Reason is that the email adress may
                    # not be verified, meaning, the user may be a hacker
                    # that has added your email address to his account in
                    # the hope that you fall in his trap.  We cannot check
                    # on 'email_address.verified' either, because
                    # 'email_address' is not guaranteed to be verified.

I want to argue that this would be a nice feature, and I'd like to offer myself to implement it if there is a reasonable chance that my patch will be accepted in the main trunk.

First, I agree that it is a security risk and that it should be turned off by default. There should be an configuration option to turn on the automatic connection.

Not all social providers are equal. Some of them, like Facebook, verify the user email and account. Facebook even sends a "verified_email": true that is saved in the extra_data column of socialaccount_socialaccount table. If the email if from Gmail, Google provider is who created the account! It can't be more verified than this.

Automatically connecting, would be a great usability enhancement. Just one click authenticating. Less friction to use my site.

Automatically connecting the accounts is a reasonable security/usability tradeoff for some selected providers.

Ultimately, I believe the security tradeoffs should be made by the site owner. The user of the library decides which risks are acceptable to run, and if a improved user experience is more important than a remote probability security exploit.

Just using myself as an example. I plan to offer just Facebook and Google as login options. My site is a hobby site, there is nothing worth to hack their user accounts. I want just an easy way to manage the identity of my users. As I said before, both FB and Google check the users email. I really think that if someone wants to hack my users accounts, it would be easier to directly hack my site than to hack FB and to use to it hack my site. The better user experience would be a greater benefit.

Please give me a "go forward" signal before I start implementing it.

All new applications created on the LinkedIn Developer Platform as of January 14, 2019 can use LinkedIn's v2 APIs. Starting March 1, 2019, LinkedIn will deprecate use of its v1 APIs.

Will django-allauth be updated to handle this deprecation?

Hello!

I have Django==1.6.1 and django-allauth==0.15.0. I use custom user model

class User(AbstractBaseUser, PermissionsMixin):
    name = models.CharField('Name', max_length=255)
    email = models.EmailField(verbose_name="E-Mail", max_length=255, unique=True, db_index=True)
    photo = StdImageField(verbose_name="Photo", upload_to="photos", blank=True, size=(290, 290), thumbnail_size=(90, 90, True))
...
    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = ["name", ]

After sign in with Twitter I got

TypeError at /accounts/twitter/login/callback/
<ImageFieldFile: None> is not JSON serializable

Traceback

Traceback:
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  114.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/providers/oauth/views.py" in view
  35.             return self.dispatch(request, *args, **kwargs)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/providers/oauth/views.py" in dispatch
  91.             return complete_social_login(request, login)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/helpers.py" in complete_social_login
  119.         return _complete_social_login(request, sociallogin)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/helpers.py" in _complete_social_login
  130.         ret = _process_signup(request, sociallogin)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/helpers.py" in _process_signup
  28.         request.session['socialaccount_sociallogin'] = sociallogin.serialize()
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/socialaccount/models.py" in serialize
  166.                    user=serialize_instance(self.account.user),
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/allauth/utils.py" in serialize_instance
  151.     return json.loads(json.dumps(ret, cls=DjangoJSONEncoder))
File "/opt/python2.7/lib/python2.7/json/__init__.py" in dumps
  250.         sort_keys=sort_keys, **kw).encode(obj)
File "/opt/python2.7/lib/python2.7/json/encoder.py" in encode
  207.         chunks = self.iterencode(o, _one_shot=True)
File "/opt/python2.7/lib/python2.7/json/encoder.py" in iterencode
  270.         return _iterencode(o, 0)
File "/home/www/.virtualenvs/site/lib/python2.7/site-packages/django/core/serializers/json.py" in default
  104.             return super(DjangoJSONEncoder, self).default(o)
File "/opt/python2.7/lib/python2.7/json/encoder.py" in default
  184.         raise TypeError(repr(o) + " is not JSON serializable")

Exception Type: TypeError at /accounts/twitter/login/callback/
Exception Value: <ImageFieldFile: None> is not JSON serializable

Advice with SESSION_SERIALIZER dont help me. Result is the same.

Submitting Pull Requests

General

• [x] Make sure you use semantic commit messages. Examples: "fix(google): Fixed foobar bug", "feat(accounts): Added foobar feature".
• [x] All Python code must formatted using Black, and clean from pep8 and isort issues.
• [x] JavaScript code should adhere to StandardJS.
• [x] If your changes are significant, please update ChangeLog.rst.
• [x] If your change is substantial, feel free to add yourself to AUTHORS.

Provider Specifics

In case you add a new provider:

• [x] Make sure unit tests are available.
• [x] Add an entry of your provider in test_settings.py::INSTALLED_APPS and docs/installation.rst::INSTALLED_APPS.
• [x] Add documentation to docs/providers.rst.
• [x] Add an entry to the list of supported providers over at docs/overview.rst.

I have been using django-allauth for a while now and every time i create a new instance i wonder why the data required for a social connection is hold into a model instead of the settings. This makes somewhat difficult having several instances and complicates the automated deployment of new instances. I know that some additional data is stored and related to the socialaccount object, but that is not something that cannot be done with settings. Is there any specific reason that i am missing for this design decision? PD. not complaining, just curious.

This is what I would consider for an email timeout system to help prevent someone from sending too many emails.

Currently the ResetPasswordForm will send a potentially unlimited number of emails every time someone fills out the form. This PR adds an option to limit how often someone can request the reset thereby limiting the number of emails they could potentially send.

At this time its only available for use on ResetPasswordForm, and ResendEmailVerification as I'm not overly sure of its usefulness anywhere else. There is a note in configuration docs stating if someone has overridden this form in particular they may need to apply the necessary code themselves.

There is a new model called EmailTimeout in the account app. If someone was malicious enough to use a bot they could very well avoid the session system thereby avoiding any sort of session storage for the limiting of emails. The model has been built under the premise of being able to be used in other locations based on the action field.

Resolves #2595 resolves #2167

This commit adds possibility to specify data you want to request from openid provider. The returned data will be stored in extra_data attribute of socialaccount.

First of all. Thanks for a great library as it takes away the pain of Auth. We are using it in a Nature Reservation project and it saves and improves the life of both Elephants and humans in South-east Asia.

Back to topic. When bumping version from 0.51.0 to 0.52.0 project failed to login Google users. Returning to 0.51.0 the login works.

I'm not 100% sure the problem resides in this project, but djangorestframework and dj-rest-auth had unchanged versions.

Trying my best to give the right information. Sentry reported this errors multiple times:

TypeError: string indices must be integers File "django/core/handlers/exception.py", line 47, in inner response = get_response(request) File "django/core/handlers/base.py", line 181, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "contextlib.py", line 75, in inner return func(*args, **kwds) File "django/views/decorators/csrf.py", line 54, in wrapped_view return view_func(*args, **kwargs) File "django/views/generic/base.py", line 70, in view return self.dispatch(request, *args, **kwargs) File "django/utils/decorators.py", line 43, in _wrapper return bound_method(*args, **kwargs) File "django/views/decorators/debug.py", line 89, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs) File "dj_rest_auth/views.py", line 53, in dispatch return super().dispatch(*args, **kwargs) File "rest_framework/views.py", line 509, in dispatch response = self.handle_exception(exc) File "rest_framework/views.py", line 469, in handle_exception self.raise_uncaught_exception(exc) File "rest_framework/views.py", line 480, in raise_uncaught_exception raise exc File "rest_framework/views.py", line 506, in dispatch response = handler(request, *args, **kwargs) File "dj_rest_auth/views.py", line 130, in post self.serializer.is_valid(raise_exception=True) File "rest_framework/serializers.py", line 227, in is_valid self._validated_data = self.run_validation(self.initial_data) File "rest_framework/serializers.py", line 429, in run_validation value = self.validate(value) File "dj_rest_auth/registration/serializers.py", line 150, in validate login = self.get_social_login(adapter, app, social_token, token) File "dj_rest_auth/registration/serializers.py", line 60, in get_social_login social_login = adapter.complete_login(request, app, token, response=response) File "allauth/socialaccount/providers/google/views.py", line 22, in complete_login response["id_token"],

This issue has been discussed before at #2454 and #2514 but was never fixed

basic scope was used to read user's profile and media but now according to documentation it has changed and user_profile scope is required and user_media is optional and basic scope does not work anymore.

When trying to login with basic scope this error response comes up:

{"error_type": "OAuthException", "code": 400, "error_message": "No valid scopes requested"}

I have subclass the Signup view class in the past and everything was successful, but since the last update, anytime I subclass the signup view, the url keeps redirecting to the sign-in page with the next parameter pointing to "users/signup"

To recreate this:

1. try starting a new django application and implement the all-auth package, then subclass the signup view and try calling the view from a url

Hello,

Is there any way in which I can use SendGrid templates via API? I want to use the prebuilt templates instead of relying on building the templates myself.

How I normally send emails in Django:

msg = Mail( from_email='[email protected]', to_emails='[email protected]', ) msg.template_id = "TEMPLATE ID"

client = SendGridAPIClient(API KEY) response = client.send(msg)

So, when user logs in i would like to have an access_token with refreshin time in DB. My users logs in by Twitch. Also I've tried to mention STORE_TOKEN = True. It doesn't work