Best way to require valid password during update action

Ash Forum Ash Questions / Help
,
1

In our app, when a user wants to update their profile settings we require their current password.

I don’t love our first implementation and wanted to check if there are other ways.

The password is checked by comparing form input against the stored AshAuth/Bcrypt password hash. We have a custom action called update_settings and a validate fn changeset, _context -> statement which checks the password and adds an error if it is not present or correct.

(We also considered a policy but that felt wrong mainly due to the desire for form feedback when the password is wrong).

Does this seem idiomatic or would you suggest another approach?

2

You should be able to reuse the password validation that exists for the change_password with password action that we generate on the user:

    update :change_password do
      # Use this action to allow users to change their password by providing
      # their current password and a new password.

      require_atomic? false
      accept []
      argument :current_password, :string, sensitive?: true, allow_nil?: false
      argument :password, :string, sensitive?: true, allow_nil?: false
      argument :password_confirmation, :string, sensitive?: true, allow_nil?: false

      validate confirm(:password, :password_confirmation)

      validate {AshAuthentication.Strategy.Password.PasswordValidation,
                strategy_name: :password, password_argument: :current_password}

      change {AshAuthentication.Strategy.Password.HashPasswordChange, strategy_name: :password}
    end
2 Likes
3

Thanks for the super fast reply! :pray: :heart:

When implementing my validation:

validate {AshAuthentication.Strategy.Password.PasswordValidation,
  strategy_name: :password, password_argument: :password} do
  where [present(:password)]
  message "Invalid password"
end

and passing it an incorrect password, I get a warning:

[warning] Authentication failed: Unknown reason
...
This error was unhandled because Ash.Error.Unknown.UnknownError does not implement the `AshPhoenix.FormData.Error` protocol.

Even though the custom error message in my validation gets passed OK through the Ash.Changeset to the form errors.

I’m not quite sure what I’m still missing to comply with the warning

4

Hmm…that is interesting. I’m not sure I fully understand why that would be happening. Could you open an issue with some more details?

5

Thanks Zach :heart:

We think the error issue is unrelated and caused by something else in the form, and likely isn’t a bug but a nested form issue that we’ve created.

I still think the original question remains though, now we’ve got this validation in place.

While your suggestion was a quick solution, I’m still wondering if it’s the right place for this check.

If Ash is going to be the business logic layer of our app, then it feels like this important security rule belongs lower down than a form/action validation. It’s important that—in all areas of the app—we don’t accidentally allow the profile settings to be updated without a password. Other security concerns similar to this might be handled via policies. Is there a case for using a policy here? (I recognise it may not be ergonomic to give form-based feedback for a policy failure)

6

:thinking:

You can do this:

validations do
  validate {AshAuthentication.Strategy.Password.PasswordValidation,
    strategy_name: :password, password_argument: :current_password}, where: [action_type(:update)]
end

For example to attach the validation to all update actions.

7

In the long term I’d like to introduce the ability for individual policies to produce user-readable error messages, until then a global validation is probably the way :smile:

1 Like
8

That seems more like what I’m after, thanks.

In theory could we could use a policy and catch the auth error in the controller to update the form error message? :crazy_face: (I won’t do this, but curious)

9

I read in the 1.8.0-rc annoucement (Phoenix 1.8.0-rc released! - Phoenix Blog) that there is a sudo plug now to do exactly this.