Authentication & storage?

Request Feedback
1

Most web apps need a way for authenticating users and storing data, with regard to simple apps how do you handle authentication & [server side] data storage (f.e. storing user preferences)?
I realize that Elm is a frontend language, but I would love to hear about your preferences & experiences on these two topics.

2 Likes
2

Authentication

I have worked using two models with Elm apps:

  1. Authentication happens in the backend server (e.g. Rails), then the Elm app is loaded, so it assumes that the user is already authenticated. We pass the user information via flags. This is simple and the app doesn’t need to know much about authentication. Every request to the api will send the authentication cookie already set by Rails.

  2. The Elm app takes care of authenticating the user, so it needs to know if the user is authenticated or not, provide a login form. The authentication was done via a JWT which is stored in local storage.
    This makes the app more complex, as you need to handle the possibility of not having an authenticated user. The benefit is that the frontend app is more standalone and thus easier to deploy anywhere.

Data storage

We store user preferences in different places:

  • In local storage, some user selections that are deemed temporary. If they change browsers then they will have to select these things again.
  • In the DB for all the important stuff that is also used in the BE.
3 Likes
3

I’m curious how you handle session expiration?

For example, the session is valid for 7 days. The app makes a request after the session has expired, what does the server do? This is kind of an edge case – presumably this situation would only occur if the app is still open when the session expiries.

4

When the session expires (or when the logout in another tab), the server responds with the login page.
When this happens our Elm decoders will fail, in this case we send the failed response to a function that checks if this is the login page by inspecting the body.
If it is the login page then we show a message to the user with a button to go to the login again.

1 Like
5

I find google firebase to be a very useful authentication and storage solution. Multiple providers for auth, in browser offline-capable storage, etc.

It is easy to use, set up and secure. The docs are great. The pricing is free initially and cheap when you need it. And the JS libraries give you a lot for free.

The two main cons against it would be vendor lock-in, and that the JS libraries are quite chunky, and depending on what you are doing can add too much payload.

The pros are productivity and scalability at a great price.

In terms of Elm it will also mean working with ports. But given the live nature of the firebase services I would say it is quite well suited for the asynchronous messaging model. If you want to write code differently you can use elm-porter or something similar instead.

6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.