Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

user session, log in / log out #883

Closed
rtrzebinski opened this issue Sep 9, 2023 · 6 comments
Closed

user session, log in / log out #883

rtrzebinski opened this issue Sep 9, 2023 · 6 comments

Comments

@rtrzebinski
Copy link

I'm looking for a way to implement user session where:

  • app starts with an empty session
  • user can sign in and his identity is kept in session
  • user can sign out and his session will be deleted

Basically storing the token in the browser would be sufficient for me to implement this. Value that would be kept even if page is reloaded, that I can access and modify at any time.

I wonder what mechanism I should be using for that, I've found this in the documentation, but seems to be for storage only:

// Returns a storage that uses the browser session storage associated to the
    // document origin. Data stored expire when the page session ends.
    SessionStorage() [BrowserStorage](https://go-app.dev/#BrowserStorage)
@oderwat
Copy link
Sponsor Contributor

oderwat commented Sep 9, 2023

This is what https://go-app.dev/states can be used for.

@krustowski
Copy link

krustowski commented Sep 17, 2023

oh no :D

  • i actually used a local storage to store logged user's struct
  • local storage is hackable easily
  • implemented AES E2E encryption for BE and FE intercommunication
  • encrypted the local storage item
  • ???
  • stonks

https://github.com/krustowski/litter-go/blob/master/backend/api.go#L16

@oderwat
Copy link
Sponsor Contributor

oderwat commented Sep 17, 2023

@krustowski I actually do not understand the problem? The local store belongs to the user. We use https://docs.nats.io/using-nats/developer/connecting/creds for authorization mostly. But if you have something on the frontend that the user is "not allowed" to modify, it will always be hackable.

@krustowski
Copy link

I wanted user not to be able to modify one field in LocalStorage (user struct). So i overengineered it a bit, used E2E encryption for the BE-FE intercommunication with a shared key, which is compiled into the WASM library a exported via env var for the HTTP server (BE).

@maxence-charriere
Copy link
Owner

Anything on client side can potentially be modified. What I did on https://murlok.io is to use JWT token with asymmetrical keys and check validity on server side before returning any data.

@oderwat
Copy link
Sponsor Contributor

oderwat commented Sep 21, 2023

@maxence-charriere this is exactly the basis of what happens when using the NATS distrbuted authentication scheme I linked above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants