Migrate from Guardian with Comeonin to Pow

Phoenix Forum Questions / Help
,
1

I’ve added authentication to my application using Guardian. However, I have zero experience with creating well written/secure authentication code for web applications. The idea that Pow provides best practices/common patterns that I can just follow - is very enticing! So I’d like to switch.

However, one thing I’m not sure about is how to migrate existing users. I’d like to use Pow on top of my existing users table - but the existing :password_hash field has been populated with a call to Comeonin.Bcrypt.hashpwsalt. I was hoping that when I tried to login with Pow, it would simply deny access and then the user would have no choice but to use the password recovery feature. But instead, it crashes.

Maybe I could get around this by setting the :password_hash field to null? Is there a friendlier way to do this?

Thanks!

2

Setting the :password_hash to nil would work. You can also continue using bcrypt, by setting the password hash methods in the user schema module (per the Coherence migration guide):

defmodule MyApp.User do
  use Ecto.Schema
  use Pow.Ecto.Schema,
    password_hash_methods: {&Comeonin.Bcrypt.hashpwsalt/1,
                            &Comeonin.Bcrypt.checkpw/2}

  # ...
end

The reason it doesn’t just deny access with an invalid password hash is that there is no reset password functionality in core Pow (it’s an extension to Pow), and you probably do want to get an error to bubble up if there is inconsistency.

3 Likes
3

Awesome! That’ll allow me to prototype my new Pow configuration and remove Guardian before I have to think about what I’ll do with Comeonin/Bcrypt…

1 Like
4

what are the downsides to using Pow?

5

Unfortunately, I don’t know. Even once I use it, I’d probably need to use something else that’s comparable.

I do know that Pow is providing equivalent/more functionality than the code I wrote for Guardian - which I have since deleted. But that’s like comparing a chair to some tools + wood.

1 Like
6

Just for note, I’m not sure what migrate from Guardian to Pow means. Guardian is a JWT wrapper library, it’s useful for server-to-server-via-client communication without sharing secrets. Pow is a local authentication framework. Comeonin is a password hasher engine, which is entirely unrelated to Guardian as the point of guardian is to be a short-lived server-to-server token (unlike Phoenix.Token, which is a local, shorter, faster, and more powerful token, but does require a shared secret, which is why it’s perfect for local-server).

So I’m confused at what migrating means, guardian isn’t authentication, it’s remote (not local) authorization… ^.^;

1 Like
7

You are completely right!

Implementing authentication for a website is a completely foreign venture for me. My research (2 years ago) lead me to Guardian as a possible option. I think I understood at the time that JWT is for server-to-server, but I also found evidence that you could use it for local authentication. So what I created is probably the worst code ever - that’s why I’m happy to be moving to Pow! :smile:

To address your comment, the title of this post is probably misleading. The migration is from the (bad) code I wrote (that utilises Guardian/Comeonin), not from Guardian itself.

1 Like
8

Sorry to dig up an old post :slight_smile: I just saw that Guardian’s README is not consistent with your last statement. So perhaps it would prevent some confusion if the use case for Guardian was better explained on Github?

guardian

1 Like
9

Well it’s not inaccurate, it’s for authentication between servers via an insecure channel, it just could stand being a lot more explicit about its usage patterns. ^.^

1 Like