Yeah, v1.0.14 introduces changes to the store API, and I forgot to update the API guide. I plan to release v1.0.15 soon, it’ll will have the updated API guide.
You just need to change the following: https://github.com/danschultzer/pow/pull/317/files
Many thanks @danschultzer!
Hi,
I have been comparing two auth packages lately, ueberauth and pow. Both look great in their own way, from my beginner’s perspective.
The way I see it is that with
ueberauth I get a solution that seems more battle-tested (12k downloads last 7 days), but I have to roll quite a few things around it myself (password reset, email confirmation, templates, etc), and with
pow I get a package that seems less battle tested (2k downloads last 7 days), but I don’t have to roll much myself.
Feels like a difficult choice. In general I would go with the the more battle-tested solution when it comes to security, but rolling my own security-related elements as a newbie is probably also not the best idea…
Any guidance from the community on how to think about the security of different auth solutions?
Thank you.
It’s not about security, but I just want to add that Pow has some more interresting extensions like PowAssent:
I didn’t already try it but I think it’s worth to be mentioned also.
How can you even measure that with the number of downloads?
Given that ueberauth existing longer than pow.
You have to look at how many issues there has been with ueberauth vs pow in a compareable timeframe (which is not easy to do).
You should also do a secrurity review of both packages to really be able to decide.
I just restate this, the number of download does not equal something being battle tested nor that it’s secured.
Hi @Schultzer, I completely agree with you. Sorry, I didn’t realize there are two Schultzers on this thread, so I just edited this post to untangle a bit 
@danschultzer: Please forgive the oversimplification, I didn’t mean to take anything away from pow. It looks like a really great solution (I have spent a lot of time with the docs and on the powauth website), and you are an amazingly responsive project owner, and I am very tempted to make it my auth solution…
I actually looked at the issue lists of both solutions in detail (and all the other ones i could find as well), plus pull requests, etc. I’m also aware that pow is younger than ueberauth and of course pow’s 2k downloads per 7 days is an impressive feat by itself.
Might you maybe have some advice for me how to get comfortable with the security aspects of an auth solution (particularly for somebody who is not very experienced)?
Again, thank you for creating pow and the generous support you have provided around it here and on github.
Yeah, that’s what I would try to figure out too, but as mentioned by @Schultzer, download numbers aren’t a great measure for how battle tested something is. Pow is used in many production grade apps, and businesses does depend on it. The same is true for Ueberauth. Beyond that, I think it becomes fuzzy which one is the better choice. You should really just focus on which one solves your problem better.
Also, Guardian is the better comparison with Pow. PowAssent (or Assent) is the alternative to Ueberauth.
Yup, don’t roll your own. I’ve tried to make it easy to both get started and to move away from Pow if you ever decide it’s not the right solution (or partially add in your own logic). So if Pow solves the problem better for you now, I would recommend going with it, and then you can switch over if you don’t find Pow to be the right choice after all.
The best would be if the library is regularly audited. I have some plans for that with Pow, but for now I don’t think any auth solutions in Elixir can be considered a secure choice, it’s just as good as it gets.
It’s definitely not. Guardian is for server-to-server single-access token stuff, it is not for session tokens or handling of that in any way of the sort.
Oh, hmm, I always thought Guardian was built for that per the docs and use cases I’ve seen? Like this: Getting Started with Guardian — Guardian v2.3.2
Nope, Guardian is for JWT style uses. Phoenix.Token is what you want for any kind of token signing and/or encryption. It’s faster, more compact (so you can store more data in it), etc… etc…
Hi @danschultzer, I’m using the Pow library and I’m finding it really easy to use so far. One problem: my application updates the user record, and I try and update the current user, but on redirect it does not keep my changes! Here’s what I’m basically trying to do in my controller:
def callback(...) do
#...
case Accounts.update_customer(user, subscription) do
{ :ok, new_user } ->
conn
|> update_current_user(new_user)
|> put_flash(:info, "Successfully subscribed to #{subscription["plan_id"]}!")
|> redirect(to: "/")
{ :error, _ } ->
conn
|> put_flash(:error, "Subscription failed")
|> redirect(to: "/")
end
end
defp update_current_user(conn, user) do
config = Pow.Plug.fetch_config(conn)
Pow.Plug.assign_current_user(conn, user, config)
end
Any ideas what I’m doing wrong? I think this should be the right way to do it…
I was able to find it in the docs, for future reference to anyone else looking: https://hexdocs.pm/pow/sync_user.html#update-user-in-credentials-cache
Thank you @OvermindDL1 and @danschultzer for your answers!
I can able to setup invitation create user flow in API. But I’m struggling to create Invitation accept flow. How to do that. Any examples on accept invitation flow would be great.
It depends how your API works, but the plug module should have all the methods you need to set it up yourself: https://hexdocs.pm/pow/PowInvitation.Plug.html#content
I don’t have any example of invitation in API, but feel free to create an issue at https://github.com/danschultzer/pow to discuss solutions, and write out examples.
Hi @danschultzer,
I have Ecto in a separate application from Phoenix. Is there a way to bring in the schema for Pow and its extensions without having to install all the dependencies (Phoenix, etc.), or should I just define the Pow-related schema and changesets manually in my User module?
No, but it’s actually the oldest PR I’ve been working on. Would love for all dependencies to be optional. When I looked at it back then it didn’t work though. Is this an entirely different app, or is it an umbrella project? I don’t believe it’s an issue in an umbrella project since dependencies are shared.
No, it’s an entirely different app in this case. I have Pow set up in another umbrella app and I’m trying to see how easy it would be to decouple the apps completely.
Looks like the schema is mostly dynamic. Any recommendations for how to extract the schema / changeset functions I need?
I can’t think of any way of doing it short of copying all necessary modules. You can try out the optional-deps branch: {:pow, github: "danschultzer/pow", ref: "optional-deps"}. Obviously it’s highly experimental. What it does is that at compile time it excludes groups of modules based on which dependency is available. I’m curious if it works for you.
Edit: Feel free to continue the discussion in https://github.com/danschultzer/pow/pull/2 if it works.
Hello, I am utilizing Pow in an umbrella app. I have two custom user schemas and a custom context module all in the same application. It seems like at the moment this means that I need to have two separate custom context modules, rather than one, because the using macro opts for Pow.Ecto.Context specifies only a single user module. I was curious if there was a way to configure the user module that the context references more dynamically based on which application hits the application hits the context module?
© Copyright Elixir Forum | Terms | Privacy & Cookies
