Pow auth app database app structure for newbie


I have been playing with phoenix and pow and have a few questions about app and database structure.

  1. Once i install a pow, i have a database for users. do i need to add new columns in that table for keys to other user tables? Or once logged in we dont use the table? make a new users table for name email etc?

  2. I added user roles to POW. I will have pages that are groups that people can join, they can join many groups. can a user in pow have multiple user roles?

Thank you for your guidance.

would love to build a “newbie how to” soon.

1 Like

Hi @lovephoenix,

  1. You can run mix pow.ecto.gen.migration -r MyApp.Repo Accounts.Account accounts to see what fields Pow expects in the user table. You can inject the required fields into your user schema by calling pow_user_fields - example here: https://hexdocs.pm/pow/README.html#ecto-changeset. That same user guide has a reference to registering your own context for the user schema so you can have your own fields etc.

  2. I don’t think Pow allows multiple roles per user. You would have to code that up yourself. Often access control rules are part of your business logic so there is no real out-of-the-box library for anything other than very simple role management in Elixir / Phoenix as far as I am aware. After fretting about this for a while I ended up writing my own bespoke policy based access control system using Pow for authentication. With Elixir pattern matching it can be quite straightforward to code up depending on your needs. You can then model role relationships against your business entities however you see fit.


This made me think. Would it be possible to have a RDBMS way of expressing authorization a pattern-match style somehow? Probably not.

Yeah, Pow doesn’t deal with user roles at all. There’s only the user role guide that suggests one way of dealing with role authorization. As @mindok correctly states, authorization is something that’s part of the business logic in your app, it’s extremely dependent on your particular setup, so Pow doesn’t really make any assumptions in this regard.

One way is to create a table that has the user_id and the group_id to deal with permissions for groups. You can also add the role to this table if necessary. Then you can have a has_many :groups, through: [:users_groups, :group] association to load all the groups a user is part of.

1 Like

Thank you all so much for your response.

@mindok - From what you say and from what i read, it seems best to keep the POW Auth table simple and create a second table to add user details and foreign keys?

and in regards to groups, what you said was perfect, was setting this design up not knowing if it was the correct design pattern. So will continue to explore, i guess i was thinking i need to create tokens and auth for groups. but auth segregates roles of functions within the scope of groups.

It’s fine to have Pow share your own user table provided the right fields are there. There may be reasons to keep it separate from your app’s user profile data but you don’t need to. Pow is designed so it can use your table provided the minimum fields are present.

With auth & auth, it’s good to spell it out - Pow handles authentication/identity and your code handles authorisation / access control - so yes, you will define the roles and the functions they perform, and also the association of users with roles.

1 Like

Hi Thanks again for the guidance.

Looking at the migrations for pow users i noticed the changesets not present. so chcked if POWs email field has validation. it does, although though its regex would have be more strict:


Or is ok to leave the current validations (not sure where pow keeps those).

so going to use a new migration file to “alter table” and add new fields to pows Users table and add “change sets” for validation (sounds correct?)

All the validations are in the Pow.Ecto.Schema.Changeset module: https://hexdocs.pm/pow/1.0.20/Pow.Ecto.Schema.Changeset.html#content

The validations are included in the pow_changeset method (the Pow.Ecto.Schema macro automatically sets up the default changeset method): https://hexdocs.pm/pow/1.0.20/Pow.Ecto.Schema.html#content

E-mail validation is notoriously difficult with RegEx. I found it impossible so I went away from it, and instead built out a spec compliant validator in Pow: https://hexdocs.pm/pow/1.0.20/Pow.Ecto.Schema.Changeset.html#validate_email/1

If you still want to use your RegEx you can just add it to the changeset:

  def changeset(user_or_changeset, attrs) do
    |> pow_changeset(attrs)
    |> validate_format(:email, @regex)


Sorry for late response and thank you for the reply. Your solution to email validation is much better. Thank you for this.

Great community here. Much appreciated.

1 Like