Since Hologram is getting production ready, and Authentication and Authorization is a crucial step in making production apps, let’s discuss how to approach authentication and authorization in Hologram.
We can create a login form and then store the user token in a cookie and session. On subsequent pages we can check for the token in the session and get a user struct from the token and put it in the session.
Or
We can use a library like Guardian etc and follow the same steps.
My questions are -
- Is this the idiomatic way to do auth in Hologram. Since Hologram routes get called before the Router pipeline in Phoenix, whats the best approach to handle this in the pipeline itself instead of checking it in the init function in every page.
- What if the user logs in on another device and clicks log out from all devices. What should happen on the existing device. Should the user be logged out if the tries to invoke any command. If yes, how to do that in an idiomatic way. Or the user should be logged out immediately (it might require Pub- Sub).
- Phoenix has introduced scopes that can help in authorization as well as multi tenancy. How can we approach authorization in Hologram. Can we create some pipelines and nest the routes in them?
Getting some guidelines on these would really help move apps to prod. Thanks.
3 Likes
Hey @sreyansjain, let me address your points:
Planned Lifecycle Method (Setup/Middleware)
Hologram will have a lifecycle method that will be invoked before component/page inits. It will probably be called “setup”, and will be treated as Hologram middleware (in place of Phoenix pipelines in the router).
The middleware will work a little differently than in Phoenix, since Hologram has different architecture and has no router. You’ll be able to create separate modules that you can plug into the setup lifecycle, and you’ll be able to use different “setup” functions in different pages. Or create specialized pages that use specific “setup” functions by default - e.g. instead of use Hologram.Page you could do use MyApp.AdminPage that will have the specialized setup implementation applied.
It will have access to raw headers and will be able to modify the input of the component/page init functions.
Current Capabilities
Since this isn’t implemented yet, I’m not ready to talk about official auth conventions, but since init/3 functions have access to server structs on which you can access/modify cookies and sessions, you can implement most auth behavior today. Commands also have access to server structs and can be authorized in the same way.
- You can use very similar approaches as in today’s Phoenix auth solutions
- Your example is reasonable - authenticate a user in an
init/3 function and save some token/user_id to a cookie for later authorization
- You can use any authorization libraries server-side (Guardian building blocks outside plug system, Ash policies, Permit, etc.)
Multi-device logout
Your example of pubsub and logging out of other devices is not a strictly Hologram-related question - this is a universal auth problem and depends on business requirements. The solution you specified seems like a reasonable approach and should be possible once Hologram has pub/sub implemented.
The current capabilities should get you pretty far for production, and the planned middleware system will make it much more ergonomic.
1 Like
