search

thunderstore-io / thunderstore-ui

Thunderstore React UI
11 stars 5 forks source link

Authentication plan #25

Open nihaals opened 3 years ago

nihaals commented 3 years ago

The first idea was to have a hacky generate endpoint which will use a session cookie to generate a token that can be used by the frontend and store this in local storage. After thinking about this more, this idea won't work as we will be doing SSR for mod pages so we can get SEO and dynamic meta tags for embeds and we won't be able to access local storage on the first navigation.

A solution could be only SSR public mods (private mods/communities could exist in the future) and if the package isn't found get the client to request from the API themselves using local storage, and if it's not found again, show a 404. This still feels quite hacky.

If we use a cookie, we need CSRF. We could have the API require CSRF only if the token is a user token (as opposed to a service account's token) or a session ID to allow the frontend and third parties to use the same API which is an OK solution but we would need to start generating CSRF tokens and embed them ourselves.

Maybe there's a better way?

MythicManiac commented 3 years ago

After thinking about this more, this idea won't work as we will be doing SSR for mod pages

It will work, since SSR rendered content will be from the PoV of unauthenticated users

nihaals commented 3 years ago

If we make sure:

We may be able to avoid CSRF tokens when using cookie authentication, but we would need to make sure we had good tests for all of these. I haven't done much research into this topic before as I'm used to using CSRF tokens in templates so I would like to actually test this with a POC to make sure everything is as expected before fully implementing this.

MythicManiac commented 3 years ago

I don't want to use cookie auth at all with the API if we can help it, and we shouldn't need to. For authed users we can always get a token via some channel, and unauthed users don't need a token.

nihaals commented 3 years ago

It will work, since SSR rendered content will be from the PoV of unauthenticated users

So something like the first solution I described?

A solution could be only SSR public mods (private mods/communities could exist in the future) and if the package isn't found get the client to request from the API themselves using local storage, and if it's not found again, show a 404.

MythicManiac commented 3 years ago

Yeah sounds about right. Additionally, we won't have "private" content any time soon since the CDN doesn't have access control, but we might have unlisted.