[Warszawa-pm] [Catalyst] obsługa aktywacji użytkownika

Maciej Grzybek mashester w gmail.com
Pon, 3 Sty 2011, 04:53:29 PST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 02.01.2011 21:04, Zbigniew Lukasiak pisze:
> 2. Problem tak naprawdę leży w tym, że authenticate nie tylko
> autentykuje ale też loguje do systemu.  Jeśli ktoś poda prawidłowe
> hasło dla nieaktywnego użytkownika to można się zgodzić, że jest
> zautentykowany, ale $c->user nie powinno być ustawione.

Zgadzam się z tym, nie powinniśmy skazywać użytkownika na tylko jedną
drogę rozwoju aplikacji. Wystarczyłoby, aby programista sam ustawiał
$c->login; jeśli autentykacja przebiegła prawidłowo.
Dałoby to większą swobodę (można przy okazji autentykacji sprawdzić
user->isactive user->isntexpired itd. itd., w zależności od potrzeb).
Rozwiązanie z $c->logout, w przypadku gdy coś nie pasuje (active,
expiration etc.), jest workaroundem wg mnie.

> A co do autentykacji w WebNano to zastanawiam się nad czymś bardziej
> ogólnym.  Kiedyś się pytałem Miyagawy co myśli na temat middleware do
> autentykacji - ale jemu się nie podoba ten pomysł i uważa, że
> autentykacja powinna być częścią frejmłorku. Może potrzebny jest
> jakiś pomysł na komponent do Placka który niekoniecznie jest
> Middleware - ale tak samo jak Middleware może być używany przez różne
> frejmłorki.  Chyba wielu ludzi o tym myśli - na przykład
> http://twitter.com/#!/clkao/status/27613002311
> 
> 
> Z.

Autentykacja jest na zbyt wysokim poziomie i zależy od logiki aplikacji
(co było widać choćby na przykładzie tej krótkiej wymiany zdań). Moim
zdaniem nie powinna być na poziomie Plack'a, który powinien oferować nam
dostęp do mechanizmów, a nie do gotowych rozwiązań, zależnych od
konkretnej logiki aplikacji. W sytuacji, gdy będziemy za dużo narzucać,
stanie się tak jak z $c->authenticate() w Catalyscie.

Zbyszku, mam do Ciebie też inne pytanie/prośbę.
Widziałem Cię w sekcji Contributors w HTML::FormHandler.
Przepatrywałem źródła w poszukiwaniu możliwości customizowania
message'ów wyświetlanych, gdy coś się nie powiodło z danym fieldem.
Zauważyłem, że Fields/Password.pm ma hardcode'owany msg w przypadku, gdy
username jest taki sam jak hasło:

return $self->add_error( 'Password must not match ' . $self->ne_username )
            if $username && $username eq $value;

Wydaje mi się, że powinno to być customizowalne, tak jak w innych
Fieldach, np. jak w PasswordConf.
Wystarczyłoby dodać:

has 'ne_username_message' => (
    isa     => 'Str',
    is      => 'rw',
    default => 'Password must not match username'
);

i zmienić tę linię:
return $self->add_error( 'Password must not match ' . $self->ne_username )
            if $username && $username eq $value;

na

return $self->add_error( $self->ne_username_message )
            if $username && $username eq $value;

Ponadto wydaje mi się, że warto ujednolicić system nazw tych message'ów,
gdyż np. w PasswordConf'ie, nazwa: pass_conf_message, jest trochę
nieintuicyjna. Pierwsze skojarzenie to "message", może tak byłoby lepiej?
Mam gdzieś przesłać patcha na tego PasswordConf'a, czy Ty już to wrzucisz?

Pozdrawiam,
Maciej 'mac' Grzybek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNIcbJAAoJEJsau/Tq/KXRZ+MQAMMjqYSvZ7Y/MtgprrLWEyDN
Y7MTbtPD9KZx56gGOiGC3sevjhYJh6KRFb49NYJaeNjZZmpMO/V4Qld5rJzJ9fMh
9R/0NorrQhycI6BrLp0+LuChy6k/uwT+2tcjRX8jEFySGI4ywG/hvIqT7w/CGpgs
dqfGglx9CQC0Xr+kAH225xo1HJ0KLlAA9bW8o+klyE1ziO1PwKWqFN/rGKA7zNO/
/4pvbDhEIceFZTQy6zeUD20L3Zxtr/ZPfrohZnfdH+LZQ7ZtYJx9nJnpD22txWZQ
a0Cw7T0kulT85KxEolEOHm9Hm9jpP2dm2SHgtCef1aFHBeZto2RyB0d9BfcBdZ8x
aK4SLsfMMBN2B4m6uvRz4gKG99fHdUmp38S2Ny9mVQyarXw802LBNmYpmOMwWgqA
SJeAHq/C+8oOS1WaRbKBPTE1GLSQN0sGHHvEOQ38h5rAY/COLSTsz1pOU1O3uzJ9
waJNWe50XXRUNYfD2CtA2Ir2FVBrCBykYtqIix4Hhp/bgY4rnup41ajYpVtMkWMx
odg8319JpiaDZdTyoaScYQjFiDq4hm3eFxXqGDR8mLaO4xqzdzYvQYzFjZOOFGNx
OZoy/7SqVKUcWPqiFDjbuOFJzqAvv2S8aZWogDq6lFAp0nr3gJKWSqMR/tSThrue
ev6zHytCYhhzHEN50lsO
=u+ki
-----END PGP SIGNATURE-----


Więcej informacji o liście Warszawa-pm