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

Your Libraries & OS Mentoring Libraries
, , , ,
21

@danschultzer - I began trying to include your library into my proof-of-concept app today and stumbled upon some newbie issues in the getting started guide (documentation). I’m not sure exactly how to fix/overcome them yet (still learning Elixir and Phoenix at the same time). I will open some issues in the GitHub repo as I go along, so that we may improve the getting started guide/documentation :smile:

2 Likes
22

Thanks! I’ve updated the readme with the instructions you need to get it working. PowAssent expects that you have already installed Pow. I hope you can get it up and running now :smile:

1 Like
23

Thanks! I realised after reading your response to my GitHub issue. I fiddled around a bit more after that and managed to put my app in an invalid state somehow by messing up the database migrations (I was playing around with some other stuff as well). Will continue tomorrow with a fresh app :smiley:

1 Like
24

Hi, I looked through the code in the repo and the differences with the other libs available for authentication, this one fits my needs because im also planning to use your oauth provider one, so it makes sense to use it instead of rolling my own Auth code.

But after following the guides, I can’t get it working. everything is installed ok and compiles, I can fire up the server, but protected routes, or even registration/new gives me this message:

function XXXX.Pow.Phoenix.SessionController.init/1 is undefined (module XXXX.Pow.Phoenix.SessionController is not available)

nofile:  XXXX.Pow.Phoenix.SessionController.init/1

my router has “use Pow.Phoenix.Router”, a call to “pow_routes()” and the “protected” pipeline added.

Given that error, maybe am I missing something obvious?

(phoenix 1.3.4, Elixir 1.7.0 (compiled with Erlang/OTP 21) )

Awesome work BTW!

1 Like
25

This will solve your issue: Pow.Phoenix.RegistrationController not available? · Issue #22 · pow-auth/pow · GitHub

You probably have the routes set up like this:

  scope "/", Powweb do
    pipe_through :browser

    pow_routes()
  end

You should remove the Powweb namespace so it looks like this:

  scope "/" do
    pipe_through :browser

    pow_routes()
  end
5 Likes
26

Yup, that certainly was what I did. My brain read it lightly and I was thinking one scope was protected, and the other not. So it made sense to me to put pow_routes() and also my root path “/” in the open one, and then I obviously added my app namespace.
I was about to copy the lib’s controllers into my app.

Thanks!

27

I’ve always rolled my own user system when building out my Elixir apps, but knew that it’s a lot of wasted effort and repeated work. I’ve looked at some of the available libraries but never felt like I would benefit from using them. I worried that setup wouldn’t be much faster/easier than building my own, and that I’d be limited in future when I want to extend or change it. (I’ve been badly burnt previously with “standard” user systems that were difficult to extend)

From reading this thread, and having a look through your README I think you’ve nailed it! Your on boarding is incredibly clear, and I look forward to using Pow on my next app! Thanks for your hard work!

8 Likes
28

Apologies if the question is naive – I looked through your README but couldn’t find the answer.

Does Pow support either (or both) of the scenarios when users cannot sign up by themselves?

  • They have to be explicitly invited by an admin and can only sign up with a link mailed to them (which expires after, say, 24h).
  • They can visit a sign up page but after the process completes they receive notification that their registration must be manually approved by an admin.

I am looking for features that allow a startup to roll out accounts gradually and not just open the floodgates from the first alpha version. So on that lane of thought, can Pow offer anything related to this desired behaviour?

1 Like
29

Pow doesn’t offer this out of the box, but it would be trivial to build.

For admin invite, I would set up a custom registration controller that calls the actions in Pow.Phoenix.RegistrationController. The controller will have a plug action that verifies that the invite token is valid. The token is invalidated upon successful registration. As an extension, it would look pretty similar to the PowResetPassword extension.

For admin approval, I would use a controller callback for the Pow registration and session controller. It’ll just halt the connection if the user hasn’t been approved, and redirect users to the sign in page with a flash message. It’ll be very similar to the existing PowEmailConfirmation extension.

Both of these would be easy to set up as Pow extensions too.

4 Likes
30

Thanks! Being badly burnt from the limitations of existing solutions was exactly my motivation to create Pow :slight_smile:

6 Likes
31

My understanding is that the difference is that KeyCloak and identity-server (and CAS) are standalone authentication servers, whereas Pow is embedded / in-elixir-app authentication system.

With standalone servers:

  1. Your app detects the user is unauthenticated (and it is required he’s)
  2. Your app redirects (HTTP redirect) to the authentication server (which can be located on the same service or on a totally different hostname)
  3. The authentication server authenticates the user (e.g. password + push notification, Facebook…)
  4. The authentication redirects back (HTTP redirect) to your app, with a proof of authentication (that may have additional user data: first name, email…) - typically a SAML assertion or an OpenID Connect id_token
  5. Your app checks the proof of authentication (checking the digital signature), and once verified throws it away and opens a cookie session

With Pow on the other side, as far as I understand, everything is done inside the Elixir app and there’s no redirections.

I guess both approaches have pros and cons, depends on your use-case (better UI with Pow, since there are no redirects - SSO on multiple domains with authentication servers since works it independently of hostnames (that are attached to cookies))

Promising lib btw :slight_smile:

5 Likes
32

Pow 1.0.0 has been released with Ecto 3.0 and Phoenix 1.4 support! :rocket:

Docs: https://hexdocs.pm/pow/Pow.html
Github: https://github.com/danschultzer/pow

Thanks to everyone who contributed and helped me refine Pow! I feel Pow is on a really good trajectory, and hope that it’ll help many move faster with their projects.

Next up will be PowAssent 0.1.0 release.

13 Likes
33

Great advice to separate the scopes :+1: Thank you for your hard work on this lib. It is really easy to configure, saves a lot of time and efforts. Works perfectly too.

3 Likes
34

Really nice, we are about to use it on prod really soon. Thank you for your time and great work.

4 Likes
35

Exciting! I’m happy to hear it has worked well for you. Please do not hesitate to write if you got any feedback or encounter any issues :smile:

3 Likes
36

I’ve only ever rolled my own session based auth in Elixir. Using Pow, how would I set up the current user so that I can use it within my layout template for use within a navbar partial? Typically I might have a nav that checks if there’s a current_user directly within the eex file and either displays the user’s name or a login/register link.

I know that this is a fairly simple use, but I don’t want to make any assumptions and this example would help me with my mental map of how to use Pow.

37

Yeah, by default Pow automatically assigns :current_user, so you can use @current_user as you’ve done previously. The assigned key depends on the :current_user_assigns_key in your Pow configuration. Alternatively, Pow.Plug.current_user(@conn) can be used.

2 Likes
38

Pow 1.0.1 has been released

Changelog: Github
Hex: https://hex.pm/packages/pow/1.0.1

This minor release makes Pow easier to work with by having better configuration error feedback and expanded guides.

Now I will work on API changes that makes it easier to customize extension behavior. I think it’s the weakest part of Pow, but I have a good idea how to make it explicit and easy for developers to understand what’s happening.

All your feedback has helped improve Pow immensely, thanks. Please keep posting!

Also, PowAssent should be up soon in a 0.1.0 release. It has been completely rewritten to use :httpc for requests, and thus have far fewer dependency conflicts. I’ve had pretty limited time these last months, and would appreciate some help review and test it properly.

8 Likes
39

Sorry I cannot help. :slightly_frowning_face:

You have struck me as the most responsive Elixir auth library author so far. Did that change due to your being busy? I plan on using your lib for a greenfield hobby project of mine and I am hopeful you can help me get past the initial confusion (I mean, assuming I cannot find my way through the docs which is not likely but still).

1 Like
40

It hasn’t changed. It takes little time and effort for me to help out with most issues compared to working on the codebase itself. It also keeps me in the loop, and helps me stay efficient. So feel free to ask anything anytime :smile:

5 Likes