Example SimpleJWT repositories: Contribute!

[Andrew-Chen-Wang]

Hi all! Due to the sheer number of requests and urges for #157 to be merged, I have created a template repository with a Django server ready-to-go. To generate a sample repository for SimpleJWT, please press the "Use this template" button so that you don't fork the repository; this way, you can rename the repository to whatever name you want (although please follow naming conventions of the React and Vue.js repos already setup. It'd be great if you could also transfer ownership to the SimpleJWT organization so that everyone knows about it -- i.e. viewable -- and can be maintained by the community).

The template repository: https://github.com/SimpleJWT/drf-SimpleJWT-server-template

Currently created repositories:

• iOS and Android (complete): https://github.com/Andrew-Chen-Wang/mobile-auth-example
• Angular (in progress): https://github.com/SimpleJWT/drf-SimpleJWT-Angular
• React (Complete): https://github.com/SimpleJWT/drf-SimpleJWT-React
• VueJS (Complete): https://github.com/SimpleJWT/drf-SimpleJWT-Vue

In the future:

• React Native
• Flutter browser
• Flutter mobile

There are other frontend frameworks like Angular (JS), Flutter (Dart), Ember (JS), etc. If I didn't create them, it just means I undervalue them (jk). I just don't want to get ahead of myself. If you want to contribute and you're using one of these frameworks, by all means @Andrew-Chen-Wang (i.e. mention me) in this issue, and I will create a repository for you.

To reiterate, you will need unittest cases. For those who want the #157 merger, at least two frontend frameworks that are used on web browsers must be completed and tested to have the PR to be considered for merger. Not only that, it must use the PR's latest commit (do not use master branch; specify a commit SHA). I cannot stress this enough: security is number one priority. To publish a package with, imo, still a highly insecure PR since there is still no one who has given me a single test repository, SimpleJWT would be doomed in vulnerabilities and CVEs.

So.... Thanks for contributing Djangonauts!

[dgmouris]

Hey @Andrew-Chen-Wang I would like to help out on this.

As a note I would like to see how you're kind of formatting your repos so that I can be consistent with what you've created. I'm just having a bit of trouble seeing: https://github.com/Andrew-Chen-Wang/mobile-auth-example as it might be a private repo and I get a 404.

Let me know if/how I can help.

Thank you so much for your time.

[Andrew-Chen-Wang]

Hi, yes I took down mobile-auth-example so that I can learn some more security concepts in mobile development before showing it again. The general way I formatted it can be seen in the Angular repository (a new PR was made). I had "server" as a Django project name and "jwt-ios" and "jwt-android" for my mobile project names (those were the top directories/in the root directory). Sorry about the mobile examples. I didn't do so well with the Android portion (it worked but the way I was saving credentials with Account Manager (I think it's what it's called) didn't feel right to me). If you're building something for React, for example, you'd have "app" at the top directory (with the [rest]( https://reactjs.org/docs/faq-structure.html underneath)) and you'd need to make sure you include the proper .gitignore for your application. If it's a repo I haven't created yet, please let me know! Cheers

…

On Thu, Aug 27, 2020 at 12:00 PM dgmouris ***@***.***> wrote: Hey @Andrew-Chen-Wang <https://github.com/Andrew-Chen-Wang> I would like to help out on this. As a note I would like to see how you're kind of formatting your repos so that I can be consistent with what you've created. I'm just having a bit of trouble seeing: https://github.com/Andrew-Chen-Wang/mobile-auth-example as it might be a private repo and I get a 404. Let me know if/how I can help. Thank you so much for your time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLG4VRSA23CXN37E5TORQTSCZ7I3ANCNFSM4OP3WW3Q> .

[dgmouris]

Hey @Andrew-Chen-Wang thanks for responing so quick that's awesome.

Before I get started I'd like to just clarify the scope of what you'd like to see. I'd also like to take a crack at the react repo first so no new repos are needed.

First what would you like the scope of the project be? Here's what I'm kind of inferring by an example repo.

• server
  • login/logout
  • one (or more) models
  • one (or more) serializer (authenticated permissions as well?)
  • one (or more) view (or viewset)
• jwt-react
• login/logout
• component that calls endpoint and renders the result (via fetch?, via axios?)
• React specific question (totally fine if this is an implementation detail) would you like the "useContext" to

Second thing that I'd like to clarify is the directory structure.

/
|-server
|-jwt-react (where the react/other frameworks are contained, the angular pr is called jwt-angular)
  |-app
...other files....

Third thing to clarify (for the front end web frameworks) would you like to just store the jwt token in localstorage?

As well I'm assuming you'd like tests on the examples, if not that's fine too.

Hopefully this will help others as well on scope. I wouldn't put this in one massive PR but any direction/scope on the above would be much appreciated. Hopefully it's of some help:) My apologies if I'm thinking way too large. Thanks so much for the help again.

[Andrew-Chen-Wang]

Sure, np. School doesn't start for another few days so I'll be able to respond quicker before September.

1. Scope of the project: show login/logout, usage of the access token when needed (you don't always need to send a token, so you will want to demonstrate that too), and using both views. When I mean using both views, (and again sorry about taking down the mobile auth repo) I mean once you receive a 401 error, you should "refresh" your access token using the refresh token. This should be a seamless process.

In the Angular repository, what happened was loic added a timer rather than just waiting for the access token is refreshed. To me, that doesn't seem good thread wise and may not be good resource wise. It's best to just keep using the same access token until you get a 401 error. Once you do, use the refresh token to get a new access token at the api/token/access endpoint (I can't remember if that's what it's called).

Also, you will need to automatically log out a user once the refresh token expires as well. When that happens, logging out the user has the same functionality as logging out due to an expired session cookie.

In the template server repository, I had a Ping endpoint that you can use. You might also want to demonstrate a POST request with some JSON to go along with it to a different endpoint.

2. Project structure:

I've never actually programmed in these JS frameworks, but they're in high demand and David said he'd be looking into #71 again at some point in time. I think the point of the project structure was that you could start the server like it was a completely different project/git repository and start the frontend like it was a completely different project/git repository.

README.md (top level to explain what's going on)
server
| -- README.md (explains how to run Django)
| -- .gitignore
| -- requirements.txt
react-app
| -- all react components
| -- .gitignore
| -- README.md (explains how to run React)

Regarding the React repo, the server should already be set up according to the template. You just need to start a React app (idk how) and put it in a completely separate folder from the server/Django folder.

You'd need a gitignore file and some instructions in the README.

3. That's a heated debate that Allow httpOnly cookie storage #71 is trying to solve. We're looking to avoid local storage, and the PR that @loicgasser tried for using httpOnly is linked in the requirements.txt in his Angular PR. In other words, the package/link that loic used in the django requirements.txt file is the one you should try to use; however, I'd like to see if you can use Allow httpOnly cookie storage #71's method first before trying his requirements. Also in other words for clarification, don't use local storage.

Hopefully that's helpful. Let me know if there are any confusing words in here; not the best when it comes to communication.

[loicgasser]

That's a heated debate that #71 is trying to solve. We're looking to avoid local storage, and the PR that @loicgasser tried for using httpOnly is linked in the requirements.txt in his Angular PR. In other words, the package/link that loic used in the django requirements.txt file is the one you should try to use; however, I'd like to see if you can use #71's method first before trying his requirements. Also in other words for clarification, don't use local storage.

Hi so my latest work on the simple jwt lib can be found here.

https://github.com/AtuzSolution/django-rest-framework-simplejwt/releases/tag/jwt_5

This is now git+git://github.com/AtuzSolution/django-rest-framework-simplejwt@jwt_5#egg=rest_framework_simplejwt

These are the things I changed

• Remove both the token and refresh tokens from the obtain and refresh endpoints
• Added some tests
• Always return the CSRF cookie in the response body when the cookie is enabled

I also did some work on the front-end which I didn't push yet:

• Implemented the 2 401 requests strategy discussed in the Angular pull request
• Ended up storing the csrf token in local storage.

My reasoning for this is the following:

The main problem you try to address when storing the token in a httpOnly cookie is XSS. In the event that someone was able to inject a script in your site, he could very well call your server and retrieve the csrf token to then send it back to his own server. It's not that much more work to do, versus getting it from local storage.
Now this is also the reason why storing your JWT token in a httpOnly cookie doesn't make any sense if you return the token value in the response body of your server.
Now, it is true that you could send a request to your own server to read the value of the httpOnly cookies, and thus steal the token, but this is only true for old and outdated browsers like IE, if you set the SameSite configuration correctly and your client is using a "modern browser" this will not happen.

[Andrew-Chen-Wang]

Right, local storage is what had to be resorted to as plain example repositories (not the original intention but as good starting points). I was just asking to see if any more Python could be done or any other pointers incorporating #71 could be included. But yeah, we basically agreed that by the time XSS does happen, it's no bueno at that point. If you can't implement the #71 PR, then definitely go for local storage usage. Having said that, using PR would at least decrease some chances of any other vulnerability; if it can't be done, any PR using local storage is graciously accepted!

…

On Thu, Aug 27, 2020 at 8:09 PM Gasser Loïc ***@***.***> wrote: That's a heated debate that #71 <#71> is trying to solve. We're looking to avoid local storage, and the PR that @loicgasser <https://github.com/loicgasser> tried for using httpOnly is linked in the requirements.txt in his Angular PR. In other words, the package/link that loic used in the django requirements.txt file is the one you should try to use; however, I'd like to see if you can use #71 <#71 method first before trying his requirements. Also in other words for clarification, don't use local storage. Hi so my latest work on the simple jwt can be found here. https://github.com/AtuzSolution/django-rest-framework-simplejwt/releases/tag/jwt_5 This is now git+git:// ***@***.***_5#egg=rest_framework_simplejwt These are the things I changed - Remove both the token and refresh tokens from the obtain and refresh endpoints - Added some tests - Always return the CSRF cookie in the response body when the cookie is enabled I also did some work on the front-end which I didn't push yet: - Implemented the 2 401 requests strategy discussed in the Angular pull request - Ended up storing the csrf token in local storage. My reasoning for this is the following: The main problem you try to address when storing the token in a httpOnly cookie is XSS. In the event that someone was able to inject a script in your site, he could very well call your server and retrieve the csrf token to then send it back to his own server. It's not that much more work to do that versus getting it from local storage. Now this is also the reason why storing your JWT token in a httpOnly cookie doesn't make any sense if your return the token value in the response body of your server as well. Now, it is true that you could send a request to your own server to read the value of the httpOnly cookies, and thus steal the token, but this is only true for old and outdated browsers like IE, if you set the SameSite configuration correctly this will not happen. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLG4VTCYUN2GQJL3BVPDW3SC3YSRANCNFSM4OP3WW3Q> .

[dgmouris]

@Andrew-Chen-Wang

I took a stab with some of the local storage SimpleJWT/drf-SimpleJWT-React#1 I don't know how far/how much you'd like for in an example repository. I'm very much open to changing this but it might be of use, my apologies if this isn't enough/you'd like more tests, I just thought having something concrete up here would be of use.

I will take a stab at implementing at #71 PR in a few days, to see if the PR is in the ballpark of what you folks want:)

Thanks for your time again.

[Andrew-Chen-Wang]

Thanks for the PR @dgmouris! I'll take a look when I have time. Regarding #71, I read online something about Axios for React. Some people use it to store API tokens and such. Hopefully that's useful for attempting to incorporate #71.

[dgmouris]

Hey @Andrew-Chen-Wang just added tests to the authentication piece to SimpleJWT/drf-SimpleJWT-React#1.

I see that there is a path to not using localStorage with axios (referring to #71) but I think it would be more appropriate to add it to another Pull Request. I wouldn't mind working on it once the PR mentioned above is looked at (and hopefully merged 😄 )

[Andrew-Chen-Wang]

Hey @dgmouris Just left my review in your PR. Definitely looking forward to a number 2 PR for such implementation!