internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pennersr/django-allauth

Issue:
Inconsistency: "site" vs "current_site" in email template context
Writing an email template is error prone because of this.



Discussion:

Resolving patch:
diff --git a/allauth/account/forms.py b/allauth/account/forms.py
--- a/allauth/account/forms.py
+++ b/allauth/account/forms.py
@@ -417,11 +417,16 @@ def clean_email(self):
         return self.cleaned_data["email"]
 
     def save(self, request, **kwargs):
-
+        current_site = get_current_site(request)
         email = self.cleaned_data["email"]
         token_generator = kwargs.get("token_generator",
                                      default_token_generator)
 
+        def deprecated_site():
+            warnings.warn("Context variable `site` deprecated, use"
+                          "`current_site` instead", DeprecationWarning)
+            return current_site
+
         for user in self.users:
 
             temp_key = token_generator.make_token(user)
@@ -430,8 +435,6 @@ def save(self, request, **kwargs):
             # password_reset = PasswordReset(user=user, temp_key=temp_key)
             # password_reset.save()
 
-            current_site = get_current_site(request)
-
             # send the password reset email
             path = reverse("account_reset_password_from_key",
                            kwargs=dict(uidb36=user_pk_to_url_str(user),
@@ -439,10 +442,13 @@ def save(self, request, **kwargs):
             url = build_absolute_uri(
                 request, path,
                 protocol=app_settings.DEFAULT_HTTP_PROTOCOL)
-            context = {"site": current_site,
+
+            context = {"site": deprecated_site,
+                       "current_site": current_site,
                        "user": user,
                        "password_reset_url": url,
                        "request": request}
+
             if app_settings.AUTHENTICATION_METHOD \
                     != AuthenticationMethod.EMAIL:
                 context['username'] = user_username(user)


Test patch:
Repository: pennersr/django-allauth

Issue:
Should ConnectionsView be AJAX-enabled?
It's the only `FormView` that doesn't include `AjaxCapableProcessFormViewMixin` in its base classes.

Is this an oversight? Or is there a reason why the mixin wouldn't work there?



Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/views.py b/allauth/socialaccount/views.py
--- a/allauth/socialaccount/views.py
+++ b/allauth/socialaccount/views.py
@@ -76,7 +76,7 @@ class LoginErrorView(TemplateView):
 login_error = LoginErrorView.as_view()
 
 
-class ConnectionsView(FormView):
+class ConnectionsView(AjaxCapableProcessFormViewMixin, FormView):
     template_name = "socialaccount/connections.html"
     form_class = DisconnectForm
     success_url = reverse_lazy("socialaccount_connections")


Test patch:
Repository: pennersr/django-allauth

Issue:
extra_data defaults to a string
If I don't intentionally overwrite `account.extra_data` then it ends up being a string:

```
>>> account = SocialAccount(user=User.objects.first())
>>> account.extra_data
'{}'
>>> type(account.extra_data)
<type 'str'>
```

This appears to be a result of the default value setting:

```
@python_2_unicode_compatible
class SocialAccount(models.Model):
    # ...snip...
    extra_data = JSONField(verbose_name=_('extra data'), default='{}')
```

It seems like I get the desired behavior like this:

```
@python_2_unicode_compatible
class SocialAccount(models.Model):
    # ...snip...
    extra_data = JSONField(verbose_name=_('extra data'), default=dict)
```

I think using a string as default used to work properly, but it probably broke with some of the more recent (within the past year) changes to `JSONField`.  Any reason not to update the default now?

I'm using Python 2.7.6 with Django 1.8.8 and django-allauth ~0.23



Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/migrations/0003_extra_data_default_dict.py b/allauth/socialaccount/migrations/0003_extra_data_default_dict.py
new file mode 100644
--- /dev/null
+++ b/allauth/socialaccount/migrations/0003_extra_data_default_dict.py
@@ -0,0 +1,21 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import models, migrations
+import allauth.socialaccount.fields
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('socialaccount', '0002_token_max_lengths'),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name='socialaccount',
+            name='extra_data',
+            field=allauth.socialaccount.fields.JSONField(default=dict, verbose_name='extra data'),
+            preserve_default=True,
+        ),
+    ]
diff --git a/allauth/socialaccount/models.py b/allauth/socialaccount/models.py
--- a/allauth/socialaccount/models.py
+++ b/allauth/socialaccount/models.py
@@ -93,7 +93,7 @@ class SocialAccount(models.Model):
                                       auto_now=True)
     date_joined = models.DateTimeField(verbose_name=_('date joined'),
                                        auto_now_add=True)
-    extra_data = JSONField(verbose_name=_('extra data'), default='{}')
+    extra_data = JSONField(verbose_name=_('extra data'), default=dict)
 
     class Meta:
         unique_together = ('provider', 'uid')


Test patch:
Repository: pennersr/django-allauth

Issue:
Facebook js_sdk fail with apostrophe in URL
This causes a JS syntax error:

``` django
{% provider_login_url "facebook" method="js_sdk" next="/foo?msg=I%27m+broken" %}
```

The problem is that the output lands in an HTML attribute, and the browser decodes it before passing it to JavaScript. The `%27` becomes a single quote which breaks the JS. The existing code calls `encodejs` but additionally needs to call `urlquote`.

I have a working fix, will submit a PR in a minute.



Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/providers/facebook/provider.py b/allauth/socialaccount/providers/facebook/provider.py
--- a/allauth/socialaccount/providers/facebook/provider.py
+++ b/allauth/socialaccount/providers/facebook/provider.py
@@ -6,6 +6,7 @@
 from django.template.loader import render_to_string
 from django.template import RequestContext
 from django.utils.html import mark_safe, escapejs
+from django.utils.http import urlquote
 from django.utils.crypto import get_random_string
 
 from allauth.utils import import_callable
@@ -64,8 +65,8 @@ def get_login_url(self, request, **kwargs):
                 kwargs.get('process') or AuthProcess.LOGIN)
             action = "'%s'" % escapejs(
                 kwargs.get('action') or AuthAction.AUTHENTICATE)
-            ret = "javascript:allauth.facebook.login(%s, %s, %s)" \
-                % (next, action, process)
+            js = "allauth.facebook.login(%s, %s, %s)" % (next, action, process)
+            ret = "javascript:%s" % (urlquote(js),)
         else:
             assert method == 'oauth2'
             ret = super(FacebookProvider, self).get_login_url(request,


Test patch:
Repository: pennersr/django-allauth

Issue:
[Question] Why is confirmation_key in the BaseSignupForm?
It doesn't seem to be used anywhere, right?



Discussion:
True.. to be removed.


Resolving patch:
diff --git a/allauth/account/forms.py b/allauth/account/forms.py
--- a/allauth/account/forms.py
+++ b/allauth/account/forms.py
@@ -337,9 +337,6 @@ class SignupForm(BaseSignupForm):
 
     password1 = PasswordField(label=_("Password"))
     password2 = PasswordField(label=_("Password (again)"))
-    confirmation_key = forms.CharField(max_length=40,
-                                       required=False,
-                                       widget=forms.HiddenInput())
 
     def __init__(self, *args, **kwargs):
         super(SignupForm, self).__init__(*args, **kwargs)


Test patch:
Repository: pennersr/django-allauth

Issue:
Typo in flash message after incorrect login.
The `LoginForm` Class of `account/forms.py` ([link](https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L69)) has `error_messages` for different login error situations.

`username_email_password_mismatch` key of `error_message` has value `"The login and/or password you specified are not correct."`. I think I should explicitly say that "The login username/email and/or password you specified are not correct".

Open for reviews. 


Discussion:
"username/email" is not correct in the case login is configured to be by email only. So in order to be truly explicit we need different messages depending on `ACCOUNT_AUTHENTICATION_METHOD`
@pennersr suppose `ACCOUNT_AUTHENTICATION_METHOD` is set to `"username_email"`, according to [docs](http://django-allauth.readthedocs.io/en/latest/configuration.html) user login method is either username or email. So, how can we figure it out whether login is explicitly username or email?

When it is set to `username_email`, it is okay to report `"The username/e-mail and or password..."`, but when it is set to just `username` or `email`, it should be explicit...

@pennersr We do have explicit messages for such cases [look](https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L76) 
Duh! :) 

So your proposal is to change:

    "The login and/or ..."

to

    "The login username/email ..."

I am okay with that, but shouldn't that be just 

    "The username/e-mail ..." ?

Cool. Should I go ahead to open a PR?
Please do...

(do note the email vs e-mail -- allauth uses the latter form)


Resolving patch:
diff --git a/allauth/account/forms.py b/allauth/account/forms.py
--- a/allauth/account/forms.py
+++ b/allauth/account/forms.py
@@ -82,9 +82,6 @@ class LoginForm(forms.Form):
 
         'username_password_mismatch':
         _("The username and/or password you specified are not correct."),
-
-        'username_email_password_mismatch':
-        _("The login and/or password you specified are not correct.")
     }
 
     def __init__(self, *args, **kwargs):
@@ -155,10 +152,15 @@ def clean(self):
         if user:
             self.user = user
         else:
+            auth_method = app_settings.AUTHENTICATION_METHOD
+            if auth_method == app_settings.AuthenticationMethod.USERNAME_EMAIL:
+                login = self.cleaned_data['login']
+                if "@" in login and "." in login:
+                    auth_method = app_settings.AuthenticationMethod.EMAIL
+                else:
+                    auth_method = app_settings.AuthenticationMethod.USERNAME
             raise forms.ValidationError(
-                self.error_messages[
-                    '%s_password_mismatch'
-                    % app_settings.AUTHENTICATION_METHOD])
+                self.error_messages['%s_password_mismatch' % auth_method])
         return self.cleaned_data
 
     def login(self, request, redirect_url=None):


Test patch:
Repository: pennersr/django-allauth

Issue:
LinkedIn - Changes to OAuth 2.0 URLs
LinkedIn flow is broken due to these changes (from August 6, 2018):
https://developer.linkedin.com/blog/posts/2018/redirecting-oauth-uas

So: 
access_token_url = 'https://api.linkedin.com/uas/oauth2/accessToken'
authorize_url = 'https://www.linkedin.com/uas/oauth2/authorization'

need to be changed to:
access_token_url = 'https://www.linkedin.com/oauth/v2/accessToken'
authorize_url = 'https://www.linkedin.com/oauth/v2/authorization'




Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/providers/linkedin_oauth2/views.py b/allauth/socialaccount/providers/linkedin_oauth2/views.py
--- a/allauth/socialaccount/providers/linkedin_oauth2/views.py
+++ b/allauth/socialaccount/providers/linkedin_oauth2/views.py
@@ -11,8 +11,8 @@
 
 class LinkedInOAuth2Adapter(OAuth2Adapter):
     provider_id = LinkedInOAuth2Provider.id
-    access_token_url = 'https://api.linkedin.com/uas/oauth2/accessToken'
-    authorize_url = 'https://www.linkedin.com/uas/oauth2/authorization'
+    access_token_url = 'https://www.linkedin.com/oauth/v2/accessToken'
+    authorize_url = 'https://www.linkedin.com/oauth/v2/authorization'
     profile_url = 'https://api.linkedin.com/v1/people/~'
     # See:
     # http://developer.linkedin.com/forum/unauthorized-invalid-or-expired-token-immediately-after-receiving-oauth2-token?page=1 # noqa


Test patch:
Repository: pennersr/django-allauth

Issue:
OAuth 1 callback URIs seem to ignore settings.ACCOUNT_DEFAULT_HTTP_PROTOCOL

The OAuth1 renders absolute callback URLs using the django request ignoring the `settings.ACCOUNT_DEFAULT_HTTP_PROTOCOL` configuration.

see https://github.com/pennersr/django-allauth/blob/f70cb3d622f992f15fe9b57098e0b328445b664e/allauth/socialaccount/providers/oauth/client.py#L71

while the OAuth2 callbacks are constructed differently 

https://github.com/pennersr/django-allauth/blob/f70cb3d622f992f15fe9b57098e0b328445b664e/allauth/utils.py#L259

This leads to inconsistent behavior when running the service behind a reverse proxy. The a OAuth2 use HTTPS as configured in the settings while OAuth1 uses HTTP.

It seems to me that both providers should use the same utility method.


Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/providers/oauth/client.py b/allauth/socialaccount/providers/oauth/client.py
--- a/allauth/socialaccount/providers/oauth/client.py
+++ b/allauth/socialaccount/providers/oauth/client.py
@@ -14,7 +14,7 @@
 from requests_oauthlib import OAuth1
 
 from allauth.compat import parse_qsl, urlparse
-from allauth.utils import get_request_param
+from allauth.utils import build_absolute_uri, get_request_param
 
 
 def get_token_prefix(url):
@@ -67,8 +67,8 @@ def _get_request_token(self):
             get_params = {}
             if self.parameters:
                 get_params.update(self.parameters)
-            get_params['oauth_callback'] \
-                = self.request.build_absolute_uri(self.callback_url)
+            get_params['oauth_callback'] = build_absolute_uri(
+                self.request, self.callback_url)
             rt_url = self.request_token_url + '?' + urlencode(get_params)
             oauth = OAuth1(self.consumer_key,
                            client_secret=self.consumer_secret)


Test patch:
Repository: pennersr/django-allauth

Issue:
Error when 500 template contains a django-allauth template tag
**Error message**: 
- `AttributeError: 'NoneType' object has no attribute 'POST'`

**How to reproduce**:
1) Create a 500 template (`500.html` in your template directory) that includes a template tag from django-allauth. For me, it was `Google Sign In` button:
```html
<!--500.html-->
{% load socialaccount %}
<a class="nav-link" href="{% provider_login_url 'google' %}">Log In</a>
```

2. Add an endpoint that is handled by Django's default 500 handler (`handler500` in `django.conf.urls`, which by default points to `django.views.defaults.server_error`)
```python
# urls.py
from django.conf.urls import handler500
urlpatterns = [
    # ...
    path('500/', handler500, name='500'),
    # ...
]
```
- The handler (`server_error`) renders the template: `return HttpResponseServerError(template.render())`
- `render` in `allauth/socialaccount/templatetags/socialaccount.py` is called
- `get_request_param` in `allauth/utils.py` is called in the line `next = get_request_param(request, 'next')`
- `return request.POST.get(param) or request.GET.get(param, default)` in `get_request_param` causes an error because `request` is `None` in this case

**Solution**:
- Add a guard statement to the function `get_request_param` in `allauth/utils.py`
- before a patch: Use a custom 500 handler instead of Django's default 500 handler



Discussion:

Resolving patch:
diff --git a/allauth/utils.py b/allauth/utils.py
--- a/allauth/utils.py
+++ b/allauth/utils.py
@@ -299,4 +299,6 @@ def get_form_class(forms, form_id, default_form):
 
 
 def get_request_param(request, param, default=None):
+    if request is None:
+        return default
     return request.POST.get(param) or request.GET.get(param, default)


Test patch:
Repository: pennersr/django-allauth

Issue:
Small typo in allauth/socialaccount/providers/facebook/locale.py
Should read appropriate rather than appropiate in the default_local docstring.


Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/providers/facebook/locale.py b/allauth/socialaccount/providers/facebook/locale.py
--- a/allauth/socialaccount/providers/facebook/locale.py
+++ b/allauth/socialaccount/providers/facebook/locale.py
@@ -48,7 +48,7 @@ def get_default_locale_callable():
 
     def default_locale(request):
         """
-        Guess an appropiate FB locale based on the active Django locale.
+        Guess an appropriate FB locale based on the active Django locale.
         If the active locale is available, it is returned. Otherwise,
         it tries to return another locale with the same language. If there
         isn't one avaible, 'en_US' is returned.


Test patch:
Repository: pennersr/django-allauth

Issue:
github provider should use Authorization header instead
GitHub is deprecating their query parameter access token based authentication in favor of setting an `Authorization:` header in the request. I *think* this should be a fairly simple change to the [GitHub provider](https://github.com/pennersr/django-allauth/blob/master/allauth/socialaccount/providers/github/views.py#L30) and adding the header to the `requests.get()` call. Happy to submit a PR for this but I'm not sure if there's anything else needed..

https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters 


Discussion:
I suspect that https://github.com/pennersr/django-allauth/blob/5b9b85593e683da28897635e9179b41f7db95ee1/allauth/socialaccount/providers/github/views.py#L30 and https://github.com/pennersr/django-allauth/blob/5b9b85593e683da28897635e9179b41f7db95ee1/allauth/socialaccount/providers/github/views.py#L42 need to change to something else. 
What I can't see (and I've never actually worked on this code) is that we're not even using any form of authentication when we do those `requests.get(...)` calls. 

Resolving patch:
diff --git a/allauth/socialaccount/providers/github/views.py b/allauth/socialaccount/providers/github/views.py
--- a/allauth/socialaccount/providers/github/views.py
+++ b/allauth/socialaccount/providers/github/views.py
@@ -26,20 +26,19 @@ class GitHubOAuth2Adapter(OAuth2Adapter):
     emails_url = '{0}/user/emails'.format(api_url)
 
     def complete_login(self, request, app, token, **kwargs):
-        params = {'access_token': token.token}
-        resp = requests.get(self.profile_url, params=params)
+        headers = {'Authorization': 'token {}'.format(token.token)}
+        resp = requests.get(self.profile_url, headers=headers)
         resp.raise_for_status()
         extra_data = resp.json()
         if app_settings.QUERY_EMAIL and not extra_data.get('email'):
-            extra_data['email'] = self.get_email(token)
+            extra_data['email'] = self.get_email(headers)
         return self.get_provider().sociallogin_from_response(
             request, extra_data
         )
 
-    def get_email(self, token):
+    def get_email(self, headers):
         email = None
-        params = {'access_token': token.token}
-        resp = requests.get(self.emails_url, params=params)
+        resp = requests.get(self.emails_url, headers=headers)
         resp.raise_for_status()
         emails = resp.json()
         if resp.status_code == 200 and emails:


Test patch:
Repository: pennersr/django-allauth

Issue:
base64.decodestring was removed in Python 3.9
I can see encodestring fixed with Python 2/3 compatibility in.

https://github.com/pennersr/django-allauth/blob/7b81531bc89ae98dc6f687611743db5b36cda9a2/allauth/socialaccount/providers/openid/utils.py#L74-L77

 In similar way this can also be fixed. 
https://github.com/pennersr/django-allauth/blob/7b81531bc89ae98dc6f687611743db5b36cda9a2/allauth/socialaccount/providers/openid/utils.py#L106

I will raise a PR.


Discussion:

Resolving patch:
diff --git a/allauth/socialaccount/providers/openid/utils.py b/allauth/socialaccount/providers/openid/utils.py
--- a/allauth/socialaccount/providers/openid/utils.py
+++ b/allauth/socialaccount/providers/openid/utils.py
@@ -102,7 +102,7 @@ def getAssociation(self, server_url, handle=None):
         for stored_assoc in stored_assocs:
             assoc = OIDAssociation(
                 stored_assoc.handle,
-                base64.decodestring(stored_assoc.secret.encode("utf-8")),
+                base64.decodebytes(stored_assoc.secret.encode("utf-8")),
                 stored_assoc.issued,
                 stored_assoc.lifetime,
                 stored_assoc.assoc_type,


Test patch:
Repository: pennersr/django-allauth

Issue:
Bug: don't assume default manager for `get_user_model()` is `objects`.
In my app, we have a custom user model with a _default_manager other than `objects`: https://docs.djangoproject.com/en/3.1/topics/db/managers/#default-managers 

```

Request Method: | GET
-- | --
http://localhost:8000/_/accounts/social/google/login/callback/?state=BhZ2MohMZdqZ&code=4/0AY0e-g6ZMPBHu_V_TXbHMtqD4yXbvS5ZWm2PHuIgjp0k0J-ceycL1qaMeAeXrq0Xl0_tew&scope=profile%20https://www.googleapis.com/auth/userinfo.profile
3.1.5
AttributeError
'NoneType' object has no attribute 'filter'
/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/lib/python3.8/site-packages/allauth/account/utils.py, line 402, in filter_users_by_username
/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/bin/python
3.8.6
['/src',  '/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/bin',  '/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/lib/python3.8/site-packages/ddtrace/bootstrap',  '/usr/local/lib/python38.zip',  '/usr/local/lib/python3.8',  '/usr/local/lib/python3.8/lib-dynload',  '/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/lib/python3.8/site-packages',  '/src/common/src/python/qcommon']
Mon, 01 Mar 2021 22:43:55 +0000
```

which hits here:
```
/root/.cache/pypoetry/virtualenvs/q-VsnhxLU2-py3.8/lib/python3.8/site-packages/allauth/account/utils.py, line 402, in filter_users_by_username
        ret = get_user_model().objects.filter(q) 
```

PR forthcoming. 


Discussion:

Resolving patch:
diff --git a/allauth/account/utils.py b/allauth/account/utils.py
--- a/allauth/account/utils.py
+++ b/allauth/account/utils.py
@@ -399,9 +399,9 @@ def filter_users_by_username(*username):
         q = qlist[0]
         for q2 in qlist[1:]:
             q = q | q2
-        ret = get_user_model().objects.filter(q)
+        ret = get_user_model()._default_manager.filter(q)
     else:
-        ret = get_user_model().objects.filter(
+        ret = get_user_model()._default_manager.filter(
             **{
                 app_settings.USER_MODEL_USERNAME_FIELD
                 + "__in": [u.lower() for u in username]


Test patch: