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
Sure! Feel free to open an issue on Github. I prefer there as it’s easier to track and help others in similar situation.
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”.
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 ?
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.
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.
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.