I have been playing with phoenix and pow and have a few questions about app and database structure.
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?
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.
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.
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.
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
|> 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.