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 
danschultzer
Pow Core Team
1
leifericf
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 
1
rccursach
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
danschultzer
Pow Core Team
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() endYou should remove the
Powwebnamespace so it looks like this:scope "/" do pipe_through :browser pow_routes() end
5
rccursach
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!
0
jdumont
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
dimitarvp
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
danschultzer
Pow Core Team
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
danschultzer
Pow Core Team
Thanks! Being badly burnt from the limitations of existing solutions was exactly my motivation to create Pow 
6
tangui
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:
- Your app detects the user is unauthenticated (and it is required he’s)
- Your app redirects (HTTP redirect) to the authentication server (which can be located on the same service or on a totally different hostname)
- The authentication server authenticates the user (e.g. password + push notification, Facebook…)
- 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
- 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
5