Pow seems like a very nice, “batteries included” way to handle user authentication in Phoenix apps. However, some of the batteries it includes (e.g., Ecto, relational databases) aren’t a good fit for my project’s current design and development setup.
I’d like to be able to use Pow, but store the encrypted passwords (etc) in some TOML files I’m already using for user profiles. Can someone point me to documentation and/or examples for this sort of setup?
Haven’t looked into most of Pow’s guts but I’d guess it’s not tightly related to a RDBMS; only to Ecto.
So if you find – or invent – a way to access those files through an Ecto interface then I’d expect Pow to work just fine after.
I suspect that you’re right, but I’d like to avoid adding Ecto to the project at the moment.
Maybe @danschultzer will correct me but I’m not seeing such a tightly bound to Ecto project to invest in an arbitrary storage mechanism without a standardised API.
Out of curiosity, what’s the problem in including Ecto in your project?
@dimitarvp is right, there’s no tight coupling so you should be able to get Pow working without Ecto or a DB. There are several ways to do it, but I would just set up a custom context and user module.
This is also how I unit test Pow so I’m not relying on Ecto/DB. The user module is necessary because it’s used to generate a changeset for the form, and to fetch the user id field dynamically for the form. Depending how your app works, you could also use the the user module to load the password from the TOML file on compile.
config :my_app, :pow,
user: MyApp.Users.User,
users_context: MyApp.Users
defmodule MyApp.Users.User do
defstruct email: nil, password_hash: nil
use Pow.Ecto.Schema
def changeset(user, _params), do: user
def verify_password(user, password), do: # Verify password here
end
defmodule MyApp.Users do
use Pow.Ecto.Context
def authenticate(_params), do: # Use params to look up user and verify password with `MyApp.Users.User.verify_password/2`
def create(_params), do: {:error, :not_implemented}
def update(_user, _params), do: {:error, :not_implemented}
def delete(_user), do: {:error, :not_implemented}
def get_by(_clauses), do: {:error, :not_implemented}
end
I imagine that since you use TOML files there will be no user create/update/delete, but only authentication. In that case, you should ensure that there is only the session controller. You can take a look at the context callbacks for specs.
You are the first person I’ve heard from that wants to use Pow in this way. I built Pow so it’s easy to decouple any group of modules (Ecto, Phoenix, Plug), but I would love to hear how it works in practice and if there’s something that can be improved. Please don’t hesitate to open any issues or PR on github 
Thanks to @dimitarvp for his feedback and for bringing @danschultzer into the conversation. Many thanks to Dan for creating Pow and supporting it in such a helpful manner.
It may be useful to explain a bit about why I’m trying to stay away from Ecto, if only because I may be confused about some of its characteristics. Here goes…
I imagine that since you use TOML files there will be no user create/update/delete, but only authentication.
My project is a bit like a wiki, so it uses persistent data in a read-mostly manner. It uses a tree of TOML files (with Markdown inclusions) for data storage and loads the data into Actors for use.
Authentication would let me (safely) provide persistent session history, user preferences and profiles, etc. I’m thinking about adding Neo4j or another backend service to support structured searching, but I don’t expect to need an RDBMS.
The project uses an umbrella app, in a variation on the approach suggested by Dave Thomas in his Coding Gnome course. The Phoenix app only handles web interaction. Other apps act as libraries and/or components (e.g., data sources).
My impression is that Ecto is closely coupled to the Phoenix app (e.g., by changesets). I’d rather avoid this kind of coupling as much as possible, keeping most of the “business logic” in the other apps.
I’m not using either changesets or contexts at the moment. Is it reasonable to assume that I won’t have to use them pervasively in order to use Pow? Any other comments or suggestions?
Yeah, my reply above should give you the building blocks so you can prevent using changesets at all with Pow.
Edit: One caveat is that you should generate the templates so you can remove the @changeset.data.__struct__.pow_user_id_field() call. I don’t think there’s any other places with expections for ecto changeset.
There were intentional efforts to keep them loosely coupled. The only coupling I’m aware of are 3 protocols that the phoenix_ecto package implements for Ecto (see Phoenix/Ecto — Phoenix/Ecto v4.4.3) though you could implement those same protocols for your own data structures.
You probably already know this but Changesets by themselves are not at all bound to any storage mechanism. You can use them just for your convenience. Ecto’s validation stack brings a lot of value even if you never persist the data.
(Ab)using Ecto as Elixir data casting and validation library | AmberBit Sp. z o. o.
As far as I can see using Changesets couples you to Ecto.Schema for describing any data that you care to validate (aside: as of 3.0 adapters, sandboxes and migrations are only included in ecto_sql, not ecto).
A decoupled way of using Schema/Changeset inside the web portion of the Phoenix app (just for validation) would require Schema/Changeset ↔ “domain types” conversion logic in the web portion in order to keep ecto out of the business logic.
Whether or not that is a worthwhile effort depends entirely on the application.
If the actual changeset (rather than validation) capability isn’t needed then using something like Vex and converting directly to-and-from the domain types may be the preferred option.
Quick update: I just released 1.0.8 today where there is no longer an expectation that @changeset is an Ecto.Changeset struct. This should make it easier for you to use Pow without Ecto 
We have small project where we are implementing a context based on CubDB. The fact that the Context behaviour is defined by an Ecto related module makes it harder and let us think before that Pow was heavily dependent on Ecto.
I think that there should be a Pow.Context behaviour instead !
It works though, but we are not using pow forms / html of course.
Hey, super sorry for the late reply, been overwhelmed with work lately.
Great point! Definitely makes sense to move the behaviour out of Pow.Ecto.Context.
And for anybody curious, it’s the operations module that glues the plug and context module together: pow/lib/pow/operations.ex at main · pow-auth/pow · GitHub
Edit: Created Move context behaviour out by danschultzer · Pull Request #503 · pow-auth/pow · GitHub thanks for the feedback
© Copyright Elixir Forum | Terms | Privacy & Cookies
