#Phoenix viewer unavailable generator
#Phoenix viewer unavailable update

A user is authorised to delete any property, is authorised to delete some properties or isn’t authorised to delete any property.

A user is authorised to access the edit route for any property, is authorised to access the edit route for a set of properties or isn’t authorised to access the edit route for properties.

A user is authorised to access the show route for any property, is authorised to access the show route for a set of properties or isn’t authorised to access the show route for properties.

A user is authorised to access the index route for properties, seeing a list containing all properties or isn’t authorised to access the properties index route.

Let’s use an example to help us understand the rules an application might need to implement: suppose we have an entity called properties, and we need to authorise users to access routes related to properties. On this step, we will implement some rules to be used by our LiveView and our template, and check, before each action, if a user is authorised.

#Phoenix viewer unavailable update

Step 3) Update the live views generated with to perform the checks, ensuring a user can really access a given route. Later we will test our plug by creating one route that can only be accessed by admins and another route that can be accessed by both admins and regular users. Later we will define some rules on our router, using plug pipelines that require a given role (or any role of a role list). We will implement a plug ourselves and use it on our controller. Step 2) Develop a plug to ensure the user has the authorisation to access a given LiveView. The authenticated part of our app will be all LiveView, and only authenticated users will be able to access it. The login action will be performed on a regular Phoenix controller (not LiveView) since manipulating the session inside a LiveView, although supported, complicates our problem. In our user database model, we will add an enum column called role.

#Phoenix viewer unavailable generator

In this step, we will create a Phoenix setup, add phx_gen_auth and use its generator to create our authentication system. Step 1) Use the plug provided by phx_gen_auth to check if a given user is authenticated. We will implement our solution in three steps: Although we can rely on the standard Phoenix Router when we change from one LiveView to another, sometimes we want to check if a user can access a given route inside the same LiveView or create for rules a given route, for example, allow a user to edit a property with a given ID but forbid the same user to edit a property with another ID. LiveView, on the other hand, doesn’t have a routing system. The way standard Phoenix routing is implemented, with plugs and its pipelines, makes it really easy to understand how everything is glued together and where is the best place to ensure a given user has the roles we are asking for. I feel the same, it’s sometimes harder to integrate an existing library than it is to implement your own code. The authorisation, on the other hand, is something that varies a lot from application to application, and some developers prefer to implement themselves, as discussed in this thread. Most apps need to implement authentication similarly, and it's usually not a good idea to roll your authentication solution: there are a lot of tricky details, and if you miss a single one of them you might end up having a severe security problem. For authorisation, we don't have that many options, but we surely have some good ones, again, implemented for regular Phoenix applications, like Bodyguard.

For authentication we can rely on libraries like Pow and Guardian, or use the library phx_gen_auth as proposed by José Valim, someone that surely understands a lot about authentication. The community has already come up with some excellent solutions for regular Phoenix applications. One of those problems is authentication and authorisation: authentication is where you prove who you are and authorisation is where the application decides what you can do.

Working with LiveView is a pleasure, but we still have some unsolved situations, or, at least, we don’t have a standard way of solving them. Lean Panda is currently developing a number of Elixir applications using Phoenix LiveView.