Using unicode in passwords fails

[tadzik]

I'm not sure if that's the right place/way to fix it, but in one of my apps the users noticed that the application dies with a 500 (ERROR users provider threw error: Wide character in subroutine entry at .../local/lib/perl5/Crypt/SaltedHash.pm line 215.). Turns out that Crypt::SaltedHash doesn't like unicode strings very much, so I put together a little patch to make it work:

diff --git a/lib/Dancer2/Plugin/Auth/Extensible.pm b/lib/Dancer2/Plugin/Auth/Extensible.pm
index 718a9ad..330ff6f 100644
--- a/lib/Dancer2/Plugin/Auth/Extensible.pm
+++ b/lib/Dancer2/Plugin/Auth/Extensible.pm
@@ -8,6 +8,7 @@ use Carp;
 use Dancer2::Core::Types qw(ArrayRef Bool HashRef Int Str);
 use Dancer2::FileUtils qw(path);
 use Dancer2::Template::Tiny;
+use Encode qw(encode);
 use File::Share qw(dist_dir);
 use HTTP::BrowserDetect;
 use List::Util qw(first);
@@ -446,6 +447,8 @@ sub authenticate_user {
     my ( $plugin, $username, $password, $realm ) = @_;
     my ( @errors, $success, $auth_realm );
 
+    $password = encode('utf-8', $password);
+
     $plugin->execute_plugin_hook( 'before_authenticate_user',
         { username => $username, password => $password, realm => $realm } );
 
@@ -827,6 +830,7 @@ sub user_password {
         }
         if ( exists $params{password} ) {
             my $success;
+            my $password = encode('utf-8', $params{password});
 
             # Possible that realm will not be set before this statement
             ( $success, $realm ) =
@@ -848,6 +852,7 @@ sub user_password {
             return unless $realm;    # Invalid user
         }
         my $provider = $plugin->auth_provider($realm);
+        $new_password = encode('utf-8', $new_password);
         $provider->set_user_password( $username, $new_password );
         if ( $params{code} ) {

Again, not sure if it's the kind of fix you're looking for, but it solved the problem for me :) Is there a better way to do it, or is it indeed a bug in DPAE?

[abeverley]

Thanks for submitting this @tadzik. I've got mixed feelings about it: part of me thinks that maybe this should be fixed in Crypt::SaltedHash. In terms of the proposed patch, I think the encoding code would sit better in Dancer2::Plugin::Auth::Extensible::Role::Provider, for the encoding to take place immediately prior to password updating and validation. We'd also need dancer2-generate-crypted-password updating, and probably some comments/tests ;-)