3 ms·

If you remember what you had to tweak for Django JWT auth - please do share. It would be interesting to hear your experiences. In terms of implementing the rea

If you remember what you had to tweak for Django JWT auth - please do share. It would be interesting to hear your experiences. In terms of implementing the react frontend, this is a common complaint: We do have a react SDK that provides React components for login / sign up UI and its one of our powerful differentiators. It also does not need redux since the login components can handle state easily within themselves. That being said, one possibility to use redux would be to check if the user is logged in or not. For that, we provide a function from the SDK that can be called (doesSessionExist) anywhere in your react app. Hopefully this gets your attention :) Either way, we'd love to hear from you on our Discord or on my email ID (search Advait on this thread). Your summary is incredibly on point and is part of our core thesis! Thank you for your candid feedback (we are also already in production environments but I understand your hesitancy). Thank you so much for the encouragement - it is highly appreciated!

arcturus17 6y ago
Sure, dj-rest-auth + simple-jwt implements JWT with http-only cookies by default, which I have embraced. Except that when you refresh the token, it no longer returns and http-only cookie (it returns the access token in the response body) due to an issue with how the two aforementioned libs interoperate. So the dev has to patch that in manually with their own code, otherwise the full token cycle is not http-only. Isn't that weird? Other issues include wiring some routes (urls, as Django calls them) so that they properly triggered password reset emails. I want to insist that none of this has been the end of the world, and extend my eternal gratitude to the authors of the libs, but I guess I was shocked to encounter this in a framework as mature as Django (I've moved to it in search of stability compared to the Node.js ecosystem, which I feel is the wild west in some respects and not as suitable for the types of web apps I develop) The other (more time-consuming) issues have been with implementing the front-end bits like I mentioned. An axios interceptor for refresh tokens, state management with Redux, the views (ugh, I love writing React but I really don't want to create another login form). I'll definitely take a look at your React code tomorrow, and I may be able to provide some additional feedback (and maybe steal some ideas too) Also, I want to commend your effort in marketing / comms - I've seen you both on Reddit and here, and this second impression on HN is what has prompted me to comment. Tbh first time I saw you on Reddit I thought this was more of a toy project but here on HN it's definitely clicked that you guys are serious. I've starred you on Github, I'm watching for new releases, and I'll mention you to my friends, but I think you should definitely keep up your active communication efforts - it's worked for me at least. Again, best of luck, and greetings from Spain!
- advaitruia 6y ago
  Yes, that sounds pretty strange - thank you for sharing. Haha yes, it is surprising on the face of it. But when you think about it, its not trivial to make that everything is seamless for all use cases. It requires a lot of time and constant iteration and feedback. Being a maintainer is anyway not easy and when you have the entire framework to maintain, these things happen more often than not. On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website). Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)

arcturus17 6y ago

Sure, dj-rest-auth + simple-jwt implements JWT with http-only cookies by default, which I have embraced. Except that when you refresh the token, it no longer returns and http-only cookie (it returns the access token in the response body) due to an issue with how the two aforementioned libs interoperate. So the dev has to patch that in manually with their own code, otherwise the full token cycle is not http-only. Isn't that weird? Other issues include wiring some routes (urls, as Django calls them) so that they properly triggered password reset emails. I want to insist that none of this has been the end of the world, and extend my eternal gratitude to the authors of the libs, but I guess I was shocked to encounter this in a framework as mature as Django (I've moved to it in search of stability compared to the Node.js ecosystem, which I feel is the wild west in some respects and not as suitable for the types of web apps I develop) The other (more time-consuming) issues have been with implementing the front-end bits like I mentioned. An axios interceptor for refresh tokens, state management with Redux, the views (ugh, I love writing React but I really don't want to create another login form). I'll definitely take a look at your React code tomorrow, and I may be able to provide some additional feedback (and maybe steal some ideas too) Also, I want to commend your effort in marketing / comms - I've seen you both on Reddit and here, and this second impression on HN is what has prompted me to comment. Tbh first time I saw you on Reddit I thought this was more of a toy project but here on HN it's definitely clicked that you guys are serious. I've starred you on Github, I'm watching for new releases, and I'll mention you to my friends, but I think you should definitely keep up your active communication efforts - it's worked for me at least. Again, best of luck, and greetings from Spain!

advaitruia 6y ago
Yes, that sounds pretty strange - thank you for sharing. Haha yes, it is surprising on the face of it. But when you think about it, its not trivial to make that everything is seamless for all use cases. It requires a lot of time and constant iteration and feedback. Being a maintainer is anyway not easy and when you have the entire framework to maintain, these things happen more often than not. On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website). Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)