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

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 :thinking:!

I was just hoping not having to do this…

1 Like

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.


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.



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?

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?

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 :smile:

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

1 Like


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 ?

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.

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

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 :wink:

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. https://github.com/pow-auth/pow_assent
  2. https://github.com/pow-auth/assent
  3. https://github.com/danschultzer/phoenix_oauth2_provider
  4. or another you may have and I have missed :wink:

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: https://hexdocs.pm/pow_assent/0.4.6/api.html#content

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

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

1 Like

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

Can it be disabled?

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

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.

1 Like

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.


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

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?

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 ?

1 Like

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.