Authentication and Authorization

[betim]

Hi,

Could you provide a good example for when a route needs authentication. What is the best practice here?

Regards

[betim]

Bump.

Hey Italy, I really like your library and am using it but I still don't have a good idea of how to protect routes (at least I can't think of best practice).

Also from what I found, this syntax:

"/login": wrap({
      asyncComponent: () => import("./routes/Login.svelte"),
    }),

to be pretty awesome.

Is there a way to also do this for components that are not loaded asynchronously, namely converting this

  import Index from "./routes/Index.svelte";
  const routes = {
    // Exact path
    "/": Index,
   ...

into:

  const routes = {
    // Exact path
    "/": import("./routes/Index.svelte"),
    ...

This would be to increase the convenience, instead of importing it first and then referencing it in routes object.

Anyway, great work! :)

[ItalyPaleAle]

@betim "implementing authentication" is a bit of a too-general topic. How does authentication work in your solution?

To start, please keep in mind that all apps built with Svelte are client-side apps, so the code is always shipped to the client in full. This means that you can't have "private" parts of the app.

Normally, authentication (and authorization) are not done in the client-side code, but in the server-side code when browsers request data. For example, you send a request to the server, and if the Authorization header is invalid (or cookie, etc), then the server responds with a "401 Unauthorized" status code, and your Svelte app redirects the user to the login page (or whatever is appropriate for your solution).

In the case above, the authentication check isn't on the route (or router), but on every request made to the backend server.

[TimKieu]

I am working around to have best practise auth & auth with this svelte-spa-router in pre-condition routes, e.g injected with login component. We can combine with iron cookies for better protection. However, this seems not the best practise compared to server-side (protect key, environment parames...) Sveltkit and iron cookies (protect client-side data).

@ItalyPaleAle Thanks much for great works. This can run on both classic nodejs and edge-runtime.

[ItalyPaleAle]

I wasn’t familiar with iron cookies, but just looked it up. I think your comment is solid, however I’d recommend sticking to standards like encrypted JWTs, which guarantee you are using “proper” crypto and have support across languages and frameworks.

closing as it seems the main question was answered for now

[betim]

@betim "implementing authentication" is a bit of a too-general topic. How does authentication work in your solution?

I have a simple REST API from which the svelte client gets data, this API is authorized from a header value, this value is stored in local storage.

To start, please keep in mind that all apps built with Svelte are client-side apps, so the code is always shipped to the client in full. This means that you can't have "private" parts of the app.

Normally, authentication (and authorization) are not done in the client-side code, but in the server-side code when browsers request data. For example, you send a request to the server, and if the Authorization header is invalid (or cookie, etc), then the server responds with a "401 Unauthorized" status code, and your Svelte app redirects the user to the login page (or whatever is appropriate for your solution).

I did it this way, but as you might imagine (someone as a Svelte writer) am not very interested in frameworks because of the cognitive load they produce. So I was more curious to ask an expert (you) in this case because writing a library like this is more complicated then it is simple.

In the case above, the authentication check isn't on the route (or router), but on every request made to the backend server.

Got it.

What about the other thing...any chance to add a wrap for normal components? It would help on making code more readable.

Thnx for your reply && cheers!

[betim]

I am working around to have best practise auth & auth with this svelte-spa-router in pre-condition routes, e.g injected with login component. We can combine with iron cookies for better protection. However, this seems not the best practise compared to server-side (protect key, environment parames...) Sveltkit and iron cookies (protect client-side data).

@ItalyPaleAle Thanks much for great works. This can run on both classic nodejs and edge-runtime.

Please don't forget to update this thread when you publish your code, I'd like to see it.

Cheers!