React SPA with Google Login (to help others who run into this)

[lsmolic]

First off, thank you so much to @pennersr for this amazing react-spa example and anyone else that has contributed to it. Honestly a phenomenal real-world application.

To dive right in, there were some initial hiccups porting this over for my own needs and I wanted to share.

One thing you might note down below is... the version number for django-allauth is 64.0.0... that is not a typo. Not sure what the cause of that was, but the previous release was 0.63.2 I believe... so, just note that incase you have a missing dep.

SETUP

Required Modules

Django >= 5.0
django-allauth[socialaccount]>=64.0.0

django conf
This was all I needed to get the SPA and Django working together. So, you don't need to go searching for others, there was one post I saw that recommened path("accounts/", include("allauth.socialaccount.urls")) but that didn't change my situation.

    path("admin/", admin.site.urls),
    path("accounts/", include("allauth.urls")),
    path("_allauth/", include("allauth.headless.urls")),

Please note that some python endpoints in the example app are 'accounts' and the react SPA has routes with 'account', they might trip you up when you are diagnosing which app is sending you to which location. If it says /account that is a redirect to the CLIENT and if it says /accounts that is a call to the DJANGO application

settings.py
These INSTALLED_APPS were all required to get things working

"allauth",
"allauth.account",
"allauth.socialaccount",
"allauth.socialaccount.providers.google",    

The middleware

 "allauth.account.middleware.AccountMiddleware",

If you want to have authentication with django admin AND social, I BELIEVE you need both of these AUTHENTICATION_BACKENDS. When I removed ModelBackend I got auth issues.

AUTHENTICATION_BACKENDS = (
    # Needed to login by username in Django admin, regardless of `allauth`
    "django.contrib.auth.backends.ModelBackend",
    "allauth.account.auth_backends.AuthenticationBackend",
)

Regarding HEADLESS setup
This was all I needed assuming you are ONLY doing social providers and that's all I'm looking for. The django admin will handle emails for admins, but I want to keep any user auth out of my system if possible.

HEADLESS_ONLY = True
HEADLESS_FRONTEND_URLS = {
    "account_signup": "/account/signup",
    "socialaccount_login_error": "/account/provider/callback",
}

Set the redirect url. LOGIN_REDIRECT_URL is where django will redirect you after the "google" or other provider callback. Please correct me if I'm wrong.

LOGIN_REDIRECT_URL = "/"

Understand the relationship of SOCIALACCOUNT_PROVIDERS and standard ACCOUNTS
In your settings file, and explained in the documentation you are making some decisions about how existing accounts will work with social account emails that may ALREADY exist in your app.

The SOCIALACCOUNT_EMAIL_AUTHENTICATION = True I'm calling out because it hung me up for a long time until I realized what was happening. I was just getting sent back to my app without the isAuthenticated = true and there wasn't any indication as to WHY.

The example django app was working for me when I pointed my own React app to it, however my own django app kept failing to authorize me.

This is around the time I finally turned on verbose logging and realized that I needed this SOCIALACCOUNT_EMAIL_AUTHENTICATION or the user would conflict with my ... wait for it... EXISTING DJANGO ADMIN USER that had the SAME email address because I was testing GOOGLE. YAY! ... so ... logging FTW, but also, look into this property and understand the ramifications. It allows your users to be "trusted". I'm okay with it because we still have an final level of approval that requires human interaction, but none the less, this is the big win for me.

SOCIALACCOUNT_EMAIL_AUTHENTICATION = True
SOCIALACCOUNT_PROVIDERS = {
 "google": {
       "APPS": [
            {
                "client_id": os.getenv("GOOGLE_CLIENT_ID"),
                "secret": os.getenv("GOOGLE_CLIENT_SECRET"),
            },
        ],
       "SCOPE": [
            "profile",
            "email",
        ],
       "AUTH_PARAMS": {
            "access_type": "online",
        },
      "FETCH_USERINFO": True,
}

CORS and CSRF issues
This was a uuuuuuuge red-herring and had me looking through tons of docs to figure out why my react app was suddenly experiencing issues with this. Sometimes calls would get through and other times the error was totally swallowed by the framework.

The example uses Docker to spin up an example. But if you (like me) are stuck in the 2000s and you don't have a docker-ized local environment this is the first place you'll want to look.

All these Keys are not necessary to get this working and setting some of them will actually cause phantom issues

CSRF_TRUSTED_ORIGINS = ["http://localhost:3000"]
CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOW_CREDENTIALS = True
CORS_ORIGIN_WHITELIST = ["http://localhost:3000"]
CORS_ALLOWED_ORIGINS = ["http://localhost:3000"]
CORS_ALLOW_ALL_ORIGINS = True

To just get the basic setup working, I HIGHLY recommend just using nginx to proxy some shared port like 3000 to your React App and Python app "backends". Once you have the app working, you can go back and mess around with CORS and CSRF tokens, but let's avoid that until the actual thing is set up. If you follow this stategy you'll just hit localhost:3000 on your browser and requests will be automatically forwarded to either you node instance running your react app on port 8000 or your django app running on port 8001. The ports don't matter, just make sure they are available and you put them in the correct place.

Here's an example config: (don't for get to restart nginx after)

server {
listen 3000;

location /api {
    # removes /api from the url before handing off to django. This handles the "BASE_URL" from allauth.js
    rewrite ^/api(/.*)$ $1 break;
    proxy_pass http://localhost:8001;
    proxy_set_header Cookie $http_cookie;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location ~ ^/(accounts|admin|static) {
     # handles admin routes, static admin assets, and allauth "accounts" routes
    proxy_pass http://localhost:8001;
    proxy_set_header Cookie $http_cookie;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location / {
    proxy_pass http://localhost:8000;
    proxy_set_header Cookie $http_cookie;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}
}

DEBUGGING (when your situation isn't quite like mine)
Set Logging to FULL and watch those incoming requests

import logging.config
LOGGING_CONFIG = None
logging.config.dictConfig(
    {
        "version": 1,
        "disable_existing_loggers": False,
        "formatters": {
            "console": {
                # exact format is not important, this is the minimum information
                "format": "%(asctime)s %(name)-12s %(levelname)-8s %(message)s",
            },
        },
        "handlers": {
            "console": {
                "class": "logging.StreamHandler",
                "formatter": "console",
            },
        },
        "loggers": {
            # root logger
            "": {
                "level": "DEBUG",
                "handlers": ["console"],
            },
        },
    }
)

React App (front end)

It first, I copied over most of the files and then slimmed the whole thing down to basically an "Auth" feature within my app that contained. The following and that was everything i needed to make the whole thing work.

components/
    - Login.jsx
    - Logout.jsx
contexts/
    - AuthContext.jsx
lib/
    - allauth.js
    - django.js
socialaccount/
    - GoogleOneTap.jsx
    - ManageProviders.jsx
    - ProviderCallback.jsx
    - ProviderList.jsx
    - ProviderSignup.jsx
routes.jsx
hooks.jsx
routing.jsx
index.jsx

Here is the app entry point:

import { AuthContextProvider, AuthRoutes, AuthChangeRedirector } from '@/features/Auth';

function createRouter() {
  const routes = AuthRoutes();

  return createBrowserRouter([
    {
      path: '/',
      element: (
        <AuthChangeRedirector>
          <Outlet />
        </AuthChangeRedirector>
      ),
      children: AuthRoutes(),
    },
  ]);
}

export default function Router() {
  const [router, setRouter] = useState(null);
  useEffect(() => {
    setRouter(createRouter());
  }, []);
  return router ? <RouterProvider router={router} /> : null;
}

// This wraps the app with the auth context from allauth so all our routes can take advantage of it, but we don't pepper allauth files all over the app.
ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
  <React.StrictMode>
    <AuthContextProvider>
      <Router />
    </AuthContextProvider>
  </React.StrictMode>
);

The other change you need to make is in lib/allauth.js if you are working with the SPA example. This is just a fix for the use of nginx or docker with one entrypoint at localhost:3000 and someway of differentiating calls to the API vs the React App. Once you have it running... you can remove this and go back to normal localhost ports, but don't forget that you still need to battle with CSRFtokens and CORS errors. I'll follow up when I'm done working it out.

import { getCSRFToken } from './django';

// LOOK FOR THIS LINE at the beginning and add '/api to the beginning

const BASE_URL = `/api/_allauth/${CLIENT}/v1`;

.... REST OF FILE ....

Finally

I saw many django web and allauth examples, but no one seemed to write up a tutorial on React in a way that solved my issues. (well, nothing can solve my neurospicy-ness, but ... I digress). This is just a hope that if you are working through a react app and finding tons of issue that this might solve one or two of them for you.

Thank you to the authors of this React/Django Example app. It is incredibly awesome that this exists and I hope more people adopt AllAuth because of it.

EDIT (2024-08-22):

If you are trying to trigger anything on "post user create", I found it a little challenging to fully understand this, especially since I am not highly experienced in django and the @receiver signals don't seem to be as reliable as Rails' "post_save" callbacks that I'm used to. Even django says that in their docs.

So the implementation for "Post Save" is to use an "Adapter" and this is documented in the allauth docs, but i was honestly not as sure how to implement, so here is a working example for anyone stuck on this. In my case, I wanted to create a "user profile" for a use because it is recommended in django to store additional properties on the profile instead of polluting the User object.

First you create a custom adapter. I'm literally calling it CustomSocialAccountAdapter just because that helps remind me that this isn't a built-in class.

from allauth.socialaccount.adapter import DefaultSocialAccountAdapter
from .models import UserProfile

class CustomSocialAccountAdapter(DefaultSocialAccountAdapter):
    # CALLED IMMEDIATELY UPON ACCOUNT CREATION
    # THIS IS WHERE WE CAN RUN FOLLOWUP ACTIONS
    # BEFORE A USER LOADS THE APP FOR THE FIRST TIME
    def save_user(self, request, sociallogin, form=None):
        # Call the super class's save_user method to handle the default behavior
        user = super().save_user(request, sociallogin, form)
        user_profile = UserProfile.objects.create(user=user)

        return user

Then in your settings.py, you need to specify your custom SOCIALACCOUNT_ADAPTER

SOCIALACCOUNT_ADAPTER = 'apps.users.adapters.CustomSocialAccountAdapter'
# DON'T confuse this with HEADLESS_ADAPTER... That's for something else..
HEADLESS_ADAPTER = "apps.users.adapters.CustomHeadlessAdapter"

Originally I tried to use a custom UserManager and set objects = CustomUserManager() on the User model, but the "create_user" method was only getting triggered when I was generating a user via the User.objects.create(). It would trigger when I was generating users in my seed data, but not in my social account login. In case you're curious it looked like this (not the line where I try to create_user_profile(user):

class UserManager(BaseUserManager):
    def create_user(self, username, email=None, password=None, **extra_fields):
        if not email:
            raise ValueError("The Email field must be set")
        email = self.normalize_email(email)
        user = self.model(username=username, email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        self.create_user_profile(user)
        return user

While the manager DID NOT work, the custom adapter did in-fact, work for me and actually, if you are wondering about that CustomHeadlessAdapter I mentioned earlier, I wanted my /_allauth/browser/v1/auth/session to return more than just base user so I could immediately do some SPA configuration. Mostly I wanted to choose where to redirect someone who was an admin or approved member, as in my case, a user needs to give us MORE information before they are officially a member. Social accounts don't provide enough in all situations.

So here is a CustomHeadlessAdapter that allows us to change how the session is represented. Please note my comment about possibly just using a custom serializer because all of this logic is technically used in other places, I just wanted to share this ASAP incase others were struggling. Cheers!

from .models import UserProfile
from allauth.headless.adapter import DefaultHeadlessAdapter

class CustomHeadlessAdapter(DefaultHeadlessAdapter):
    # THIS IS THE SESSION "USER". IT WILL RETURN THESE EXTRA FIELDS...
    # TODO: WE MIGHT BE ABLE TO CHANGE THIS TO USE THE NEW OwnedUserSerializer
    #  from .serializers import (OwnedUserSerializer)
    def serialize_user(self, user) -> dict:
        # Call the parent method to get the base serialization
        ret = super().serialize_user(user)

        # Add custom fields
        ret["is_admin"] = user.groups.filter(name="Admin").exists()
        ret["is_member"] = user.groups.filter(name="Members").exists()
        # Get the UserProfile and attach it here.
        user_profile = UserProfile.objects.get(user=user)
        if user_profile:
            ret["profile"] = {
                "bio": user_profile.bio,
                "city": user_profile.city,
                "country": user_profile.country,
            }

        return ret

and as I said above, don't forget to set:

HEADLESS_ADAPTER = "apps.users.adapters.CustomHeadlessAdapter"

Please ask any questions. I'm happy to answer any if you stumble upon this and want to know more.

[pennersr]

Thank you for this detailed write up! Hope it helps others...

[Altair2169]

hey, thats a really great writeup, the nginx config really helped out, I did auth a little differently, I am using React Query for server-side state, so instead context its more hooks based and that actually simplified auth a lot.

I just had a couple of questions:

1. I have split out the backend and frontend to separate subdomains, so I am assuming allauth expects absolute urls instead of relative ones? same with the LOGIN_REDIRECT_URL, I dont think you need to specify the redirect url because in the SPA example, socialaccount_login_error is hit every time and based on the error query param, the the frontend either sets the auth or shows the error. and then the frontend explicitly handles the redirect in ProviderCallback.js
2. By any chance, did you face any errors using google oauth? I am authenticated successfully but I am redirected to the socialaccount_login_error url with these params account/provider/callback?error=unknown&error_process=login and the error info isnt exactly helpful in diagnosing the cause

[Altair2169]

Hey, I did the preliminary debugging with these steps before and none of them really worked out, tried on different browsers and different accounts and same issue, refer to #4041 for more info

[lsmolic]

Maybe it's related to using session management. Have you tried implementing it with the standard configuration to get it working before changing session management strategies?

[Altair2169]

yeah, I'm not using AllAuth's sessions, I am just using allauth's auth management, these are the installed allauth apps I have enabled

    "allauth",
    "allauth.account",
    "allauth.socialaccount",
    "allauth.headless",
    "allauth.socialaccount.providers.google",
    "allauth.socialaccount.providers.microsoft",

    ```

[davidyytan]

hi does your method work if the backend and frontend is on different subdomain?

[Altair2169]

@davidyytan what do you mean by method?

[lsmolic]

I edited the post (see the bottom of my post for update 2024-08-22). Adding support for a custom user's session (not usersession) serializer and also adding functionality "post_save", which was actually really difficult to figure out for me since i'm not as familiar with django's @signal functionality. I tried to use those first, but never received any of the callbacks for headless, socialaccount, or account. maybe someone else has experience with that would could share.