Nice library. Will definitely check it out for my next app!
egeersoz
danschultzer
Pow Core Team
Yeah, there’s a section about it in the readme describing how you can use Phoenix.Token instead of the default Pow session under Authorization plug: GitHub - pow-auth/pow: Robust, modular, and extendable user authentication system · GitHub
blatyo
Conduit Core Team
Oh, thanks. I missed that.
Also, want to say thanks for this library. It’s been a pleasure to work with so far.
axelclark
I just replaced coherence in my ex338 app. Using the Migrating from Coherence guide was very straightforward. I used the PowPersistentSession, PowResetPassword and PowInvitation extensions with Swoosh Mailer. I also used Redis cache store backend guide since I host it on Heroku.
It took me a few commits to get all the configuration set up, but here are the 1st two commits for anyone interested.
https://github.com/axelclark/ex338/commit/a386e80046ed2f7a6c05e104b06f1761434a483d
https://github.com/axelclark/ex338/commit/4a34d8d38bba580bcef9a786214de451a06972b9
…through…
https://github.com/axelclark/ex338/commit/c3b1b8b6893fcd44f7e9d921a79813eddd7fbcbb
ryloric
Hi!,
Thanks for the wonderful library, it was a breeze to setup and get it working took very little time 
One tiny issue I noticed is that the Cache-Control headers that come by default for the /session/new and /registration/* routes are not ideal. Pow’s internal controller sets the header to max-age=0, private, must-revalidate for the login form page. This means, if a user logs in through the login page and clicks the back button on the browser, the login form will be shown again and he won’t be automatically redirected.
IMO the Cache-Control header for all session and registration routes should be set to no-store by default so that if the user navigates to the login/signup pages via history, the user is redirected properly instead of being shown a stale form.
What do you think?
danschultzer
Pow Core Team
That’s great to hear, thanks!
The cache control header is what Plug sets by default (same default that rails uses). Pow doesn’t set anything. It’s a good question whether Pow should set a cache control header.
Doesn’t the default header mean that the cache is revalidated right away? The max-age is 0, so the cache is stale from the get go, and must-revalidate ensures that stale response is not used. I only have limited understanding of browser cache, but it looks like the above should trigger a new response (that would be the redirect as the user has been authenticated).
ryloric
True, but the subtle difference here is how the back button works in browsers. Unfortunately browsers don’t respect expiry or max-age directives in Cache-Control when it comes to history-lists. There is a good longer-form explanation here.
So, say a user while logged in, types out session/new in the address bar and presses return, the browser notices that the login page is stale since max-age is 0 and sends a request to the server, at which point phoenix knows they’re already logged in, and redirects them appropriately. This works as expected.
Instead, If the user clicks the back button and goes to session/new somewhere in their history, they will just see the login page again and they can interact with the form, resubmit it etc.., we do not want that to happen. I can make gif to show this behavior when I get home.
I think this happens because, the private directive tells the browser that /session/new can be cached by the browser locally, and history doesn’t respect max-age being 0, so no request is triggered and the form shows up again.
If we set no-store directives, then this doesn’t happen. Nothing from the response is cached, so even if the user goes to session/new via back-button, the browser still has to make a fresh request at which point phoenix will redirect appropriately.
Just to be sure, I checked how github handles this, and they do have no-store, no-cache in Cache-Control.
danschultzer
Pow Core Team
That’s a good point. I’ve added an issue and opened a PR for this (using no-cache, no-store, must-revalidate):
https://github.com/danschultzer/pow/issues/212
https://github.com/danschultzer/pow/issues/213
I’ll investigate this a bit more to see how other auth systems handles it, and what is the most common approach.
ryloric
Amazing speed and responsiveness!
I’m still digging around to see what’s the best possible option to use. I found https://redbot.org from MDN which I used to check the Cache-Control headers for a few well-known websites. So far, Twitter, Github AirBnB seem to set no-store.
lud
I would like to build a small game where people can be invited with a link to an open game. I will prompt them to create an account or just click a button “Play without an account”.
I would like to know if Pow can support this. Basically I would create a user with a random nickname and no email.
I find this solution simple : there is always a user ID available in the game code, no need to have two different mechanisms.
Would it be hard to have Pow to accept creating users without an email ?