The moment you decide to isolate Frontend from Backend,
you must decide how you would like to host them, i.e. the endpoints for frontend and backend.
You have two options here
- host both the frontend and backend under the same domain with reverse proxy configuration
- host front end in a domain and backend in another domain
In case of option 1 (front end and backend hosted under the same domain) you can manage to use session authentication.
You could design the login form in Django and redirect to the frontend url upon successful login.
You need not have to worry about CORS Cross Origin Resource Sharing since both FE and BE are under the same domain.
Both the session and csrf cookie will automatically be attached to all your requests from FE.
In case of option2, you cannot use session authentication since session cookies are domain specific.
You have to resort to JWT or OAUTH2.0 (which in turn are based on jwt) for authentication.
I recommend starting out with Django Rest Framework Simple JWT along with Django REST Framework.
If you search for if JWT is secure, you will get responses like it is not as secure as session authentication.
It is still the methodology used in most of the applications which has a dedicated frontend.
I would recommend you to reconsider your backend technology choice.
This is because, when you decide to isolate frontend from backend, you lose most of the "Batteries included" in Django.
You are not going to use Forms, Templates, Tables and Authentication.
That is pretty much all the good stuffs that Django offers.
If I were in your situation, I would use FastAPI for backend.
Thanks,
SWARUP Selvaraj
On Monday 20 May 2024 at 20:39:08 UTC+5:30 zvo...@seznam.cz wrote:
With traditional frontend (like realized with Django templates), the user will GET the login form and in this step Django sends csrf token. Later, in 2nd step, you send credential and the csrf token to the server.But in Django + Reactive frontend (Svelte in my case, but it is not important at all) solution, the Login form is created by Svelte. Them submission: not the real submission, but under the Submit button Svelte sends credentials to Django using FetchAPI. Maybe this submission is the 1st communication to Django server and so we haven't the csrf token yet (?!)So I have realized the Session Authentication without any regard to csrftoken cookie. My login view is wrapped by csrf_exempt. Svelte form sends credentials, Django makes login() and sends sessionid cookie back. It works.Now my question is: Is this solution safe enough? Or is it danger and I should first get the csrftoken cookie from server in some earlier request and add the header with csrftoken?It is pain to have such question.AI cannot answer it, instead it will write lot of text and code examples, without answering YES or NO, without understanding what I am asking.Find other sources is difficult (StackOverflow) is difficult too. On one side many people say Session Authentication is safe for browsers, JWT is not safe at all (because the token is saved in LocalStorage, not KeyChain). On other side, it looks like almost nobody uses Session Authentication and in problems many people say: Just go to JWT.That are reasons why it is difficult to realize the Session Authentication. But once realized, it is supereasy - no code, just the built-in cookie mechanism.So what do you mean?Or can you recommend some source which describes reactive frontend + sessionid & csrftoken cookies?
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0d969dd7-b76e-400a-81b4-8fd7312ac115n%40googlegroups.com.
No comments:
Post a Comment