auth: session managment

[MRita443]

We should investigate a way to keep track of a user's auth state (logged in/out) in the frontend, in order to be able to display specific functionalities only when authenticated.

[AvilaAndre]

I've been stuck in this issue for a while now.

The solution I was going after was to verify if the user is logged in every time a request is not successful. While this could work, it depends on the responses from the backend and ends up adding a layer of unpredictability if we do not take them into consideration each time we make a request.

For example:

const response = await fetch('get_event_info/event_id')

The code above could return a 401 (unauthorized) status code.

Does this mean that the user is not logged in or that he simply cannot access event_id specifically? The backend should have that information, of course. But if, for some reason, it is not respected in the backend, my solution would set is_logged_in to false.

However, if the we take into consideration every request for the backend, we can add the special cases for the responses we are expecting.
For the example above, we would read the backend's documentation and deal with each expected (and unexpected) response.

I believe there shouldn't be an extra layer of logic between the backend and the frontend. Having so, will possibly bring more problems in the future as it can become unpredictable. From my point of view, if we do need to see if the user is logged in, we should make the request directly to the backend server.

We can use the +page.server.ts files to verify if the user is authenticated.
The code is really simple.

export const load: PageServerLoad = async ({ fetch }) => {
  const response = await fetch('/api/auth');

  if (response.ok) {
    // User is authenticated
  } else {
    // User is not authenticated
  }
};

I could create an utils class for this though, so we just call isAuthenticated() and it returns true or false.

What do you think @MRita443 ?

[MRita443]

We discussed this today, and we collectively came to the conclusion we don't need to know the login state of the user, instead we need to know the permissions of the user. When using the /hasPermission endpoint, it returns 403 whether the user is logged out, or logged in and without permissions, so we do not need to make that distinction.

Instead, we agreed on creating a new endpoint to return the string to number mapping of the permissions, and propagating that on the frontend using something like svelte contexts. Then, every page would make a request to that endpoint to know whether to display an editing/deletion/creation button. We need this new endpoint in order to decouple the most we can the frontend and backend when it comes to permissions, otherwise the frontend would have to be aware of all of the available permission numbers and what they mean through something static, which we didn't think was great.

We also discussed things like caching a specific user's permission on the frontend or more radical ideas like the frontend handling permissions, but we agreed that those options either had problems in terms of security or of division of concerns with too much frontend logic, as opposed to more requests per page.

What do you think? If you agree I can alter/close this issue and you could redo this new idea.

[MRita443]

We discussed this today, and we collectively came to the conclusion we don't need to know the login state of the user, instead we need to know the permissions of the user. When using the /hasPermission endpoint, it returns 403 whether the user is logged out, or logged in and without permissions, so we do not need to make that distinction.

Instead, we agreed on creating a new endpoint to return the string to number mapping of the permissions, and propagating that on the frontend using something like svelte contexts. Then, every page would make a request to that endpoint to know whether to display an editing/deletion/creation button. We need this new endpoint in order to decouple the most we can the frontend and backend when it comes to permissions, otherwise the frontend would have to be aware of all of the available permission numbers and what they mean through something static, which we didn't think was great.

We also discussed things like caching a specific user's permission on the frontend or more radical ideas like the frontend handling permissions, but we agreed that those options either had problems in terms of security or of division of concerns with too much frontend logic, as opposed to more requests per page.

What do you think? If you agree I can alter/close this issue and you could redo this new idea.

We still stand by this but as the current system of calling the /hasPermission endpoint with a permission number works fine, this is more of an improvement so we decided to remove this from the MVP.