I am trying to set a cookie that is permanent until changed

Sessions: are gone when the browser is closed

Cookie: Great for permanent data like a location. However, you can’t access cookies from the socket.

To safe-guard your application, Phoenix limits and validates the connection information your socket can access. This means your application is safe from these attacks, but you can’t access cookies and other headers in your socket.

The solution when using LiveView? Read the cookie in a conn plug, set it in the session and pick it up in the LiveView again.

LiveView access to cookies

Local storage: this is not send to the server but you might be able to preselect the right location with a Javascript hook. This saves you the hassle of a cookie read, session set and session get.

Hi Bart

Thanks for the response but I don’t think I need to use liveview on the landing page right?

So when the user hits the site for the first time, I ask for permission to location, then I find the nearest station, I suggest that station might be their home station and if it is or they choose one I set the cookie accordingly.

None of that needs to be liveview but ordinary Phoenix?

Once I have the cookie I can start using Liveview ?

Not sure I understand. LiveView is never a mandatory technique, but when used is might brings benefits over ‘dead views’ in scenario’s with a certain ration of interaction.

Assuming the server is the one finding the nearest location and you don’t mind an old-school full page ‘refresh’ after submitting the location to the server, dead views can do just fine (and simple with cookie). You have a hidden formfield, put the detected location in, submit the form and just handle the form as we have done for decades.

Once you want to use LiveViews in combination with the location, you need to somehow transfer the data in the cookie to the live view process (which can be on an different machine). So usually this is done by reading it in a dead view, setting it in the session and read the session once the live view is mounted.

Session has two meanings here:

First, there is the Plug.Session which is a k/v store (often called a Session in webdev) which stores data either in a cookie on the client (Plug.Session.COOKIE) or in an :ets table (Plug.Session.ETS).

Then, there is what is termed a “session cookie”, which is a cookie with no expiry set. When you set a cookie with no expiry (or max-age), the browser will delete that cookie “when it feels like it”, which is usually when the window or browser is closed (but not always).

If you use Plug.Session out of the box, you are probably using the Plug.Session.COOKIE store with the default settings. The default max-age for the Plug.Session cookie (which is configurable) is nil, meaning the cookie will have no expiry. This leads to the following unfortunate statement:

The “Session Cookie” is stored in a “session cookie”.

But it does not have to be a “session cookie” in which you store your “Session Cookie”, because you can set the :max_age option for Plug.Session, and then your Session will survive the browser being closed

But yeah, in practice you can just set a cookie and then load it into the session instead of doing that. That’s what phx.gen.auth does.

BTW, to actually answer the OP:

It is fine to store your flag in a cookie.

If you decide you want to use LiveView, you won’t be able to access the cookie directly, but you can copy it from the cookie to the session and then to the assigns. If you want to see an example of this, run phx.gen.auth on an empty project and have a look at user_auth.ex, particularly ensure_user_token/1 and on_mount/4.