I wrote "I think this backend can create the cookie in the final stage of the first login" but I think it should be done at the end of each captive page login (also auto-logins).
So to recap, this is more or less the flow: - user enters username and password hits "login" - captive page app sends an async HTTP POST request to the Node JS backend - the backend sends the POST to the obtain-token-auth endpoint of openwisp-radius - openwisp-radius replies to the backend - the backend repliesto the captive page app and returns the token (maybe we can set the cookie at this stage, but we will have to turn off this setting: https://django-freeradius.readthedocs.io/en/latest/general/settings.html) - the captive page app uses the token to log in the user in the captive portal (it's another request, either GET or POST, you will have to mock it in your environment because you don't have a captive portal running) Ask more questions if needed. Federico On Fri, Apr 5, 2019 at 4:22 PM Federico Capoano <[email protected]> wrote: > Storing in local storage has been reported to be not the most secure > option: https://auth0.com/docs/security/store-tokens#single-page-apps > > I think the session cookie can be set at this stage: > > At successful login, the backend code should obtain a new user access >> token, encrypt it in a secure way (eg: with a secret key that is different >> for each organization and is accessible only by the backend, or an >> equivalent secure way) and the resulting encrypted token shall be stored in >> a signed cookie, served via HTTPS only (this feature shall be enabled by >> default and it should be possible to turn it off if needed) > > > Remember it's the node JS backend of the captive page which talks to the > API of openwisp-radius, I think this backend can create the cookie in the > final stage of the first login, if I remember correctly though, the backend > cannot do this on its own but needs the client (the JS frontend app) to > send a request to it and the backend sends the cookie in the response, so > it should be the very last step of the login, we may or may not need an > extra HTTP request to the node JS backend for this operation, it's better > to not overthink this now because everything we say or write now may be > invalidated when we try it out, we need to try it out, that's why I'm > stressing on the prototype. > > Federico > > On Fri, Apr 5, 2019 at 3:03 PM Vivek Rajput <[email protected]> wrote: > >> Thanks fed for the clarification. Also can you please explain me the flow >> of the auto login feature. In earlier apps I have worked on, I used to >> obtain the user token from API and then store it in the local storage of >> the client. And the next time users opend the app, it used to check the >> token in the local storage and redirected the user accordingly. And I used >> to send that token with the subsequent requests. But I haven't used >> encrypted cookie for the purpose. So would be good if you could explain the >> flow of the how everything will be done. >> >> Vivek >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenWISP" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
