Improving dev time by using JWT local and Session Cookies production

[Andrew-Chen-Wang]

Copied from here

Since I've never used a JS framework before, I have zero clue what the ramifications are regarding constantly rebuilding the app... In the following, I'm proposing a middleware that acts as a replacement for SessionMiddleware such that your JWT token and Session cookies during DEBUG=True and False, respectively, and are set on request.session.

The reasons being is that we want to take advantage of React reloading a lot faster than rebuilding. Anyways, the original quote:

Currently, it's pretty fast for me since there's nothing there. But I worry that when a single change happens, then constantly rebuilding using npm-watcher would be horrific.

I was thinking instead we could let local authorization be handled by SimpleJWT (so that we don't need to keep running npm run build) and production be handled by session. To deal with storing session data or JWT payloads, we can create a middleware in a different package that can handle the different environments based on settings.DEBUG. The reason we can interchange the two is because we're just dealing with secret payloads that the client can't see, only the server. By having one method for handling different contexts (e.g. like setting a new key in the payload or a new key for session payload), it abstracts away the complexity of the app.

But before that last paragraph, I just want to know how fast npm run build is, at least for a React app. Thanks!

[Andrew-Chen-Wang]

I'm planning on integrating this with cookiecutter-django... maybe if it's approved that is. Unfortunately, that might put a lot of maintainability issues on browniebroke, so may not. I may just create a template repository; however, I really love the layout of cookiecutter-django.

Perhaps another tutorial would be helpful.

The problem I see is that when you integrate JWT, you'll need to add some React components to the login page to handle everything. Everyone's login page is different... maybe we can add some JS code that works for everyone! Eh tbh, the only thing the developer needs to do is save the JWT in a non-httpOnly-flagged cookie. Maybe just add that into the tutorial instead.

However, if this is the case, then I may need to create a new repository as this repository is not necessary anymore. The only thing we can takeaway from this repository would be that GitHub action to deploy, but even that is not truly necessary since according to @stunaz, many people split their frontend repo with their backend.

---

I think that's game plan. Let's make a middleware that handle DEBUG mode differently.

I already have a split settings file, so what I can do is have local use USE_NODE = os.environ.get("USE_NODE", DEBUG) where USE_NODE helps the middleware identify if we should be dealing with sessions or JWT.

[Andrew-Chen-Wang]

The only concern now is build/index.html. I have no idea if that changes. We also have to transfer build/index.html to the backend repository if we're dealing with two repositories... Which is the whole reason why I had this in one repository to begin with.

Edit: Ah they do.... I forgot about the manifest/hashes in the links and scripts
(please ref this in regards to build/index.html: https://stackoverflow.com/questions/65795669/does-react-build-index-html-change-every-time-you-bundle)

[Andrew-Chen-Wang]

We can do the same method we did for the static files: reply to GitHub. In the same GitHub action, we can determine a server repository, and using the same build, transfer our index.html file to our backend repository. Wherever your template repository is, it'll always include build/* but not build/static/*. If you're testing the UI along with your server (but still in two different repositories), you'll just need to make sure you always do a git pull. In your favorite IDE, you can do something like git fetch origin master:master on load (good practice regardless of project).

[Andrew-Chen-Wang]

What I'm going to do is use SimpleJWT's template repository for React but also include the showing of DEBUG vs. RELEASE mode via the JS... if that makes sense. What you can do is in your index.html file, include a context variable from settings specifying {{ value:json_script:"debug" }} where value = {"data": settings.DEBUG} and your JS can do:

if (JSON.parse(document.getElementById("debug")).data) {
   // 1. Show a login form so that your JS can collect inputs via event listeners (as in <form action="." method="post" onsubmit="loginSubmit()"></form>)
   // 2. authenticate via SimpleJWT by saving token in cookies
} else {
  /*
1. Show a login form that actually does a POST request to the server. This means the user actually does the submission, not your form (as in <form action="ACTUAL URL" method="post"></form>)
2. The trick to know whether your user failed to submit login details/failed to authenticate is to quickly set in your sessionStorage whether you were on the login page. When your SPA reloads, just read your sessionStorage to see and load accordingly. Your web page automatically reloads because the "form" tag does the post request for you. When your web page reloads, the server has set the HTTPOnly cookie.
*/
}

[Andrew-Chen-Wang]

@dgmouris @loicgasser The above is how we should implement the template repositories.