Thanks for the insight. And I will definitely adopt the “dead view” term. 
This is exactly what I had in mind. We have a login screen that uses form fields, that would otherwise use the exact markup as the ones inside our live views. Do we bite the bullet and just suffer the duplication between the markup in this regular EEx template and our Surface components?
That’s what I did for the /login, /signup, /password-reset etc views. I have them hard-coded with classic Phoenix.HTML code until it will be possible to bring in Surface stateless components. They’re rather simple in nature, so the hardest thing was to keep the style in sync with the rest of the app (how an input/button/form is styled since you can’t re-use the components where these are set).
I even do auth in live_view. It is not the most efficient way but the uniformity is very pleasing.
How do you do it? I think you still need to do like a page redirect to set the cookies, so at one point the LiveView has to redirect to a controller, which performs session operations, and then goes back to LiveView, right? That’s how I do it but maybe I miss on something…
I don’t use cookie. I use LocalStorage to store the JWT token client side and send it back to LV on mount for it to verify.
If the token check out, go ahead. If not, push_redirect to a simple LV backed login form.
Yes. It is fairly simple, please refer to the linked code. This is my javascript in its entirety for one project; all 60 lines of it.
https://github.com/derek-zhou/liv/blob/4692306b4f30faabc90b286fcf745e8a4c2efc65/assets/js/app.js#L31
For authenticating with Surface, I recommend using phx_trigger_action to send the user to a regular form handler route rather than trying to do it completely in the LiveView:
I initially was unaware of this feature and went a more hacky route. You don’t need to involve extra tokens or local storage or anything. If you’re looking for an out of the box solution, phx_gen_auth is great:
Using it with LiveView/Surface involves some translation, but the important back end bits (which use industry grade security) stay the same.
Yes my way is unorthodox but I have exactly one secure token in localStorage, no cookie. The token is the same industry grade JWT token (I use Guardian like before), the password hash (I use Argon2 like before) is not exposed to the client side. And I have zero controller. I believe it is as secure as a controller based auth.
For authentication with LiveView, isn’t it possible to store a token in the socket, then have liveview use this token to load user details on mount ?