Pow: Robust, modular, extendable user authentication and management system

[Exadra37]

@outlog

afaik Pow uses ecto - so you can try using patatoid / ecto3_mnesia · GitLab

Oh I was not aware of ecto3_mnesia I just came across the one for ecto2.

Now I am using Memento in conjunction with Ecto schemas and changesets, but maybe with ecto3_mnesia is more straightforward… I think I may switch to ecto3_mnesia !

@outlog

you would need to replicate the Pow ecto migrations into a script creating the db tables as per the ecto3_mnesia readme…

I was just hoping not having to do this…

[Schultzer]

You don’t have to use Ecto.

You can create your own users context that uses :mnesia rather the Ecto.

But you properly want to use Ecto for the changeset to leverages all the builtin functions and changeset in Pow.

[danschultzer]

@Exadra37

In my understating Mnesia is used by Pow to persist sessions, and what I am asking is if Pow supports to use Mnesia also to persist the created users, aka when you register for the fist time, because I don’t see this mention anywhere, not even in the linked docs, but I may had misunderstood something.

Pow was built to use Ecto, but as @Schultzer mentions, you are not bound to Ecto, or using the migrations. Depending what you are looking for you could just create a custom Repo module, but you could also ignore the whole Ecto part of Pow and set up a custom users context. Pow is very flexible here.

Feel free to open an issue on Github if you would like to see some examples of customizations. I would want to see how you currently persist structs in Mnesia to give a more detailed answer.

What @outlog suggests is likely the easiest integration though.

@Exadra37

By the way congrats for the awesome work you have done with Pow

Thanks!

[Exadra37]

@danschultzer

Pow was built to use Ecto, but as @Schultzer mentions, you are not bound to Ecto, or using the migrations. Depending what you are looking for you could just create a custom Repo module, but you could also ignore the whole Ecto part of Pow and set up a custom users context. Pow is very flexible here.

So my current take is to use Mnesia for the persistence layer while still leveraging the Ecto changesets magic, that also requires an ecto schema to be available, thus by your words I should be looking into building a custom repo in order to keep leveraging the Pow Ecto functionality for changesets and schemas?

@danschultzer

I would want to see how you currently persist structs in Mnesia to give a more detailed answer.

My current work is in a very earlier phase, thus it doesn’t have any user functionality added into, because I am planning to build it just after I have implemented Authentication and Authorization via some cools library like Pow or similar.

But I can share how I persist the other struct if you want?

[danschultzer]

@Exadra37

So my current take is to use Mnesia for the persistence layer while still leveraging the Ecto changesets magic, that also requires an ecto schema to be available, thus by your words I should be looking into building a custom repo in order to keep leveraging the Pow Ecto functionality for changesets and schemas?

Yeah, I think that would be the easiest, and you would be able to leverage it with your default Phoenix Ecto setup too.

Looking at ecto3_mnesia, I think it would carry you most of the way though. You don’t need to set up migrations, you just have to ensure that the tables are there. I really like Memento though, would be great with an Ecto adapter built on top of it

@Exadra37

But I can share how I persist the other struct if you want?

Sure! Feel free to open an issue on Github. I prefer there as it’s easier to track and help others in similar situation.

[lud]

Hi,

What would be the best strategy for a single page application ? I am looking at the API guide but it feels like reimplementing the whole thing (I know it is not), meaning a lot of code to maintain. Is it the best way for SPAs, especially if we want to build a native android app after the web app is stable ?

In the web app, we would then have to manage the access token and renew it every 30 minutes. And to automatically sign in the day after, we would have stored the renew token, for example, in localstorage which seems a bad practice to me.

So I wonder if there is a better way of doing things, letting pow handle validation, session and auto-login through cookies. We would just have to manage cookies on a native app (or implement the whole API thing) but the web app would be more “standard”.

Thank you

Edit: Maybe that would be add custom controllers who defdelegate everything to the base Pow controller except for respond_create and other “respond” functions. Then I could just return JSON from those functions. Side question: do I need a custom AuthErrorHandler with custom controllers ? In my case yes, to return JSON, but generally speaking ?

[danschultzer]

Yeah, you should still use cookies in this case (keep using Pow.Plug.Session), but set it up with custom controllers. There’s an issue on Github where I’ve put an example for SPA integration: https://github.com/danschultzer/pow/issues/353#issuecomment-612467149

So kinda the same as the API guide except you don’t need a custom authorization plug, and can keep on using Pow.Plug.Session.

[lud]

Ok that’s great, and it seems easy. I’ll do the same with registration form. Thank you very much.

[Exadra37]

@danschultzer

Sure! Feel free to open an issue on Github. I prefer there as it’s easier to track and help others in similar situation.

Before I start opening issues in Github I need to first decide what one of your repos I will use, because you have so many that I am confused

I just want to support login with Github, Gitlab , Google and Twitter, and I don’t want to have the traditional user registration where I need to have the registration forms and have to store their passwords, but I want all of the rest that an Authentication and Authorization system have to offer.

So what one should I use?:

1. GitHub - pow-auth/pow_assent: Multi-provider authentication for your Pow enabled app
2. GitHub - pow-auth/assent: Multi-provider framework in Elixir
3. GitHub - danschultzer/phoenix_oauth2_provider: Get an OAuth 2 provider running in your phoenix with controllers, views and models in just two minutes
4. or another you may have and I have missed

[danschultzer]

@Exadra37

So what one should I use?:

PowAssent would be the right choice, it does everything for you out of the box.

There’s an API guide here, though with SPA it would make most sense just to use the default controller flow as you anyway need to redirect the user: How to use PowAssent in an API — PowAssent v0.4.6

[Exadra37]

@danschultzer

There’s an API guide here, though with SPA it would make most sense just to use the default controller flow as you anyway need to redirect the user: How to use PowAssent in an API — PowAssent v0.4.6

Sorry I should have mentioned that I am still using a Phoenix web application and no API.

[danschultzer]

Right, in that case the default PowAssent setup will be all you need.

[Exadra37]

@danschultzer

Right, in that case the default PowAssent setup will be all you need.

I have installed PowAssent but it forces me to use the traditional User Authentication flow that I said I don’t want to use:

@Exadra37

I just want to support login with Github, Gitlab , Google and Twitter, and I don’t want to have the traditional user registration where I need to have the registration forms and have to store their passwords, but I want all of the rest that an Authentication and Authorization system have to offer.

Can it be disabled?

[danschultzer]

@Exadra37

Can it be disabled?

Yeah, just remove the Pow registration routes. Then customize the sign in page to only have the social provider links.

[Exadra37]

Thanks but that doesn’t change the behavior, neither the Pow Assent to disable registration.

Don’t waste more your time with me here… If I decide to go with Pow Assent I will open an issue in Github.

Thanks for your time and being so helpful and quick to reply.

[buddhisthead]

Hi Dan,

I’ve been using POW since 1.0.18 and it’s been great. I just updated to 1.0.20 so that I can use the persistent sessions. It’s clear for web pages, but I’m using an API for most things and would like to add the 30-day persistent session window to my API routes as well. I started going through the code and got lost. Any hints on how to add this to my session routes would be appreciated. Thanks!

BTW, I read the thread on the new push for mix generated auth; and I’m sticking with POW for my forseeable future - it’s robust and has lots of great features and production integration. Thank you for your work on this.

[lud]

API routes called from javascript in the browser share the same session cookie as regular HTML routes so you have nothing special to do.

[buddhisthead]

Thanks, lud. I’m not using Javascript from a browser; it’s being called from a client inside a game using an http client. Do I just need to know the name of the cookie and save it’s value, then return that key/value in the header of a get/post to an API endpoint?

[lud]

In that case I guess you shoud follow this guide that allows to maintain a token based session. It seems to support persistent sessions too.

Edit: by the way i’m very interested in Elixir gaming. Do you have anything public to show about your game ?

[buddhisthead]

I’ve followed that guide and it doesn’t discuss long-term persistent tokens (30-day); it appears to address renewable tokens, which require constant refreshing (30-seconds) and won’t be helpful for the case where clients aren’t running for periods of days. For most games requiring authentication, it’s desirable to allow offline access, but have things updated when the connection is available. For this, we use a silent account refresh on game startup, using an authentication token from a previous session. A 30-day “must log back in” is acceptable, as long as we can update the account info on each game startup. That’s needed for things like trial expiration, account blocking, feature updates, user nickname changes, etc.

This game is written in Unity, not elixir. I am just implementing the server side in Elixir/phoenix/pow.