If I authorize users inside the mount function of a liveview, does that protect the event handlers as well? For example if I redirect inside of a mount function, will that disallow access to the event handlers over the socket connection?
1 Like
If I understand right, you want to read: Security considerations of the LiveView model — Phoenix LiveView v0.17.11 in full.
Permissions might change while someone is logged in, so on mount may not be enough. There are 3 places you might secure: mount/on_mount, each handle_event, and when permissions change you can disconnect all the affected user forcing them to log in again. The above docs will hopefully help you decide based on your circumstances.
Thanks, I’ve read the guides on the topic though. I’m not a fan of the solution that they propose with the context methods such as Users.create_account(current_account, new_account). I’d rather have authorization as another layer in the application. Is there a widely used authorization library in elixir? I’m a big fan of pundit in rails. A few came up in my search, namely bodyguard, canary, and a pundit clone for elixir.
I usually end up rolling my own until I know what kind of access control I need long term, and how quickly it will evolve into Attribute Based Access Control. If I’m lucky it’ll only ever be a minimal role based with hardcoded roles that aren’t going to change, but I’m not usually lucky. I usually end up reimplementing something in-between policy_wonk and bodyguard and making a custom queryable or two per context that may define scopes when I need it to be a part of a complex query too
I’ve only ever needed to migrate to one of them once and it was fine. But I’ve usually been in the healthcare space where authorization is usually a lot more complicated than typical use case these libraries are designed to solve for. It’s not that they can’t do them or anything, just that it’s easy to abuse them early on, instead of rethinking your boundaries when things get messy.
My only experience with canary was working with a bunch of recent ruby devs who loved action hooks and wanted something familiar, but my feeling is that it hides the need for more contexts by normalizing reimplementing the authz logic in a new controller.
