Re: [Catalyst] Using Progressive realms when username and password fields are all different

2012-06-30 Thread Tomas Doran

On 29 Jun 2012, at 10:59, Will Crawford wrote:

 On 28 June 2012 23:12, Gavin Henry gavin.he...@gmail.com wrote:
 ...
 Thanks Tim. Yes, I know that but then the other two realms will fail
 and that's the point of progressive. I want to call one -authenticate
 which tries all the realms I've defined in progressive_oauth.
 
 Regrettably, the docs for the Password realm saith:
 
NOTE If the password_field is something other than 'password', you
 must be sure to use that same field name when calling
 $c-authenticate().
 
 I'd call that a bug, personally - it certainly isn't intuitive that
 you can specify the field to use, but then have to remember it in all
 your calls to authenticate().
 
 Not much can be done about that, though. Maybe someone can produce an adaptor?

I don't disagree that it's confusing, however it _is_ intentional, as you can 
pass an arbitrary hash of data into $c-authenticate for the auth info 
(allowing you to do lookups on the values of multiple fields).

What happens is that the configured 'password_field' is _removed_ by the 
Password credential when it calls the 'find_user' method, and then the 
remaining fields are passed to the store to lookup a user with - this allows 
you to say $c-authenticate({username = $u, password = $p, is_admin = 1});

For example.

Patches to improve the documentation would be welcome, of course! :)

Cheers
t0m


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Using Progressive realms when username and password fields are all different

2012-06-30 Thread Tomas Doran

On 29 Jun 2012, at 21:18, Gavin Henry wrote:
 The main problem is that and the fact that username_field is missing.
 
 I'd like to do -authenticate( { username = $blah, password = $blah2 })
 
 if username_field and/or password_field is in the config, map those to
 above values, if not
 just use the default. Otherwise there's no way you can use a
 Progressive realm with
 non-consistent user/pass field names in your DB. I could add a
 viewbut it's not my
 DB.
 
 Silly or sane?

What you want / need is to be able to re-map the auth-info in some way before 
(or at the time of) the call to $realm-find_user

I'd suggest that C::Authentication::Realm be patched to support a 
'authinfo_mangle' config key, which would look something like this:

{
add = {
some_key = 'some_value',
},
remove = [qw/ some_other_key /],
rename = {
from_field_name = 'to_field_name',
}
}

This would allow you to add/remove/rename arbitrary fields that were passed 
into $c-authenticate({}); - this would solve the issue in a generic way, right?

Cheers
t0m





___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] ANNOUNCE Catalyst-Runtime 5.90015

2012-06-30 Thread Tomas Doran
Hi

I'm pleased to release the latest maintenance of Catalyst - 5.90015.

This release fixes regressions and incompatibilities resulting from he 
refactoring in 5.90013, and is a highly recommended upgrade for anyone using 
versions 5.90013 or 5.90014.

Full change log below as always.

Cheers
t0m

--

5.90015 - 2012-06-30 16:57:00
  - Fix $c-finalize_headers getting called twice. RT#78090
  - Fix test fails in Catalyst-Plugin-Session-State-Cookie. RT#76179
  - Fix test fails in Catalyst-Plugin-StackTrace
  - Fix test fails in Test-WWW-Mechanize-Catalyst


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/