Hey!
I am an experienced web developer but I find HEEx templates extremely annoying to work with. It slows me down a lot. I’d love to use Phoenix solely as backend and build my frontend with Vue.
Now I am facing an issue in which phx.gen.auth offers me two options: liveview based and controller based configuration. I’ve picked controller based. So far so good.
My issue now is that I had to disable the CSRF plug to even get a request to /users/register through, so I’m wondering if I should even use Phoenix at this point. The auth clearly did not have in mind that I’d use a different framework for my frontend. It does not seem framework agnostic.
So is it even a good idea to only utilize Phoenix as backend? I really don’t want to work with HEEx templates.
1 Like
Hello,
What exactly about HEEX bugs you ? I have stopped all new development with Vue and now exclusively use Liveview, for UIs that are quite very interactive.
Before that I have used Phoenix+Vue a lot, is serving the Vue app from the same host as your Phoenix app not an option ?
The standard Vue+Vite stack runs on vite’s dev server port, but you mount your UI in your Phoenix root layout. In prod, Phoenix serves the compiled assets.
Phoenix can be a generic backend framework like any other.
1 Like
HEEx is just very annoying to write compared to what I am used to. Writing server side rendered components is also not really enjoyable for me. I separate my Vue app from my Phoenix App as I’ll also have to add a Flutter App at some point and I want everything separated.
With using HEEx I won’t have the option to use the auth flow in other stacks.
So to utilize Phoenix as generic backend I’ll have to figure out how to use phx.gen.auth in a generic way. Currently, without much customization, it’s not possible to register or login without heavily editing the plugs.
The setup phx.gen.auth generates is indeed not “agnostic” – that’s expected. In the past Jose maintained a ruby library for authentication and that experience showed that authentication is hardly ever something you can provide “as is”. There’s always customization needs. Therefore on phoenix auth comes as a generator, which means it becomes your code you’re free to adjust to your needs.
One of those things it was built to is cookie based sessions, so csrf protection is necessary.
From your post it’s hard to say if you intend to use cookie based sessions as well here or of you’re hosting the SPA completely separate and aim to use different means of request authentication. If the latter than CSRF would also not be needed, when there’s no cookies, there’s probably no request forgery attack vector. How that applies is for you to know. The framework cannot anticipate how you want to setup stuff like that.
I’m sure you saw this but there’s an official guide on how to add authentication on top of code that phx.gen.auth generates for you if you don’t want to start from scratch:
The SPA is completely separated. I will have to add different stacks eventually as I plan to use it as auth for Flutter apps too. So basically I need to rely on my own auth experience and tinker around until it works? Usually I was recommended to NEVER roll my own auth. Adjusting generated auth feels pretty dangerous considering I am not an expert on auth. I simply want e-mail password login with a Bearer Token. The Phoenix Frontend wont be used for anything.
I did add this. But I still have to hit the register/login routes that move through the browser pipeline. The browser pipeline expects CSRF protection for example. What the API Auth does is simply fetch the user if there alrdy is a token.
Yes. What’s the problem? I don’t think there is a generator for API version of registration pages. If you want registration done through API, you have to implement it separately. Basically you’ll have to translate the controllers generated through phx.gen.auth to your API flavor of choice and you can delete the generated code then. And don’t put it in the :browser pipeline butin :api or create :unauthenticated_api that doesn’t check token.
Have you had a look at
https://inertiajs.com/
might be something you are interested in.
There’s may levels here. You indeed don’t want to implement e.g. you own cryptography. But there’s many different ways people authenticate nowadays, there’s lots of different ways API requests are structured. This cannot be dealt with without the need for some level of customization. That customization will be at the controller levels, not where tokens are generated and such.
That’s exactly not what I want, but I appreciate the idea
If you want login and registration over an API you need to write those endpoints yourself but I mean… thats not rocket science?
