[Catalyst] Re: Patch for Catalyst::Plugin::Unicode::Encoding
* Tatsuhiko Miyagawa [EMAIL PROTECTED] [2008-03-19 07:20]: Some modules like XML::LibXML adds UTF-8 flags regardless of if the characters to handle are composed of latin-1 range (like Encode::decode_utf8 instead of utf8::decode), and that's pretty much realistic and sane approach I think. Yes. If the flag is to have any use at all, then it has to have the semantic of distinguishing character vs byte strings. I agree with Bill that the plugin trying to decode already utf-8 flagged string doesn't make any sense, but furthermore, I wonder under which circumstance the plugin tries to decode already-utf8-flagged strings. I'd say that's the root problem. Yes; and that’s exactly what Jon said. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ 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]Catalyst::Plugin::Authentication::Store::DBIx::Classdeprecated?
Quoting Octavian Rasnita [EMAIL PROTECTED]: From: Tobias Kremer [EMAIL PROTECTED] I suggest removing the old C::P::Authentication store/state backends completely and installing the new ones to avoid clashes between old installations of your app and possible future ones. I'm not sure, but having two different installations (one with the old version and one with the new) caused some trouble for me in the past where the app ran fine on one machine but was broken on the other one ... Thanks. Are there any settings changes need to be made after this? Or I would just need to uninstall the older modules and install the newer ones? I _think_ it should work right out of the box. I had some trouble after the upgrade because we have a legacy (mod_perl) application that reaches inside the session data to find the user (authenticated via C::P::Authentication) and the internal structure of the session hash changed. But if you're not doing anything insane like that you should be fine :) Just make sure that you really have the old C::P::Authentication store/state backend modules deleted, otherwise they'll still be used which _could_ lead to some confusion. --Tobias ___ 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] developer.yahoo.com
On 18 Mar 2008, at 12:29, Chisel Wright wrote: On Tue, Mar 18, 2008 at 02:13:22PM +0200, Octavian Rasnita wrote: Do you have any idea why? None at all. Have you tried asking _them_? http://developer.yahoo.com/perl/ exists, is not linked. I've set things in motion both to fix that and to get some much needed love for the subsite itself. -- Mike Whitaker| Perl developer, writer, guitarist, photographer [EMAIL PROTECTED] | Board member, http://www.enlightenedperl.org/ Y!: tuxservers | Blog: http://perlent.blogspot.com/ IRC: Penfold | Yahoo! UK Ltd - internal CMS team ___ 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] Re: Patch for Catalyst::Plugin::Unicode::Encoding
Aristotle Pagaltzis wrote: * Tatsuhiko Miyagawa [EMAIL PROTECTED] [2008-03-19 07:20]: Some modules like XML::LibXML adds UTF-8 flags regardless of if the characters to handle are composed of latin-1 range (like Encode::decode_utf8 instead of utf8::decode), and that's pretty much realistic and sane approach I think. Yes. If the flag is to have any use at all, then it has to have the semantic of distinguishing character vs byte strings. I agree with Bill that the plugin trying to decode already utf-8 flagged string doesn't make any sense, but furthermore, I wonder under which circumstance the plugin tries to decode already-utf8-flagged strings. I'd say that's the root problem. Yes; and that’s exactly what Jon said. There are a number of ways that incoming data could already be decoded: environment, perl switches or pragmata, ideally every application would do as Jon proposes and ensure that nothing decodes the string before the plugin sees it. But checking the flag before decoding is at worst harmless and at best prevents data corruption: it would prevent already-decoded strings becoming deformed, decode encoded UTF-8 (or whatever) strings and leave unflagged ASCII strings alone, whether or not decode had already be attempted. Perhaps the best approach would be to warn and not decode when flagged data is seen, that way the data should never be deformed and the author can see that something else is decoding too early and they can fix it. Matt ___ 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] developer.yahoo.com
This is only tangentially related: I noticed recently that Yahoo moved their official how to interact with Yahoo SearchMarketing sample Perl code from a simple Perl file to a proper program using a real CPAN released library. This seems to be a part of their v4.0 SearchMarketing API release. I can't determine from the CPAN library itself that it is really official (you have to look at the Y! Developer page for that), so I don't know how you'd be able to figure out if any other given CPAN library is official without the exact type of site you're asking for! References: http://searchmarketing.yahoo.com/developer/docs/V4/sample_code/perlsdk.php#code http://cpan.uwinnipeg.ca/module/Yahoo::Marketing http://search.cpan.org/~shenj/Yahoo-Marketing-4.03/lib/Yahoo/Marketing.pm Anyway, I thought if you were looking for Y! SM specific stuff this info might be helpful. -d Mike Whitaker wrote: On 18 Mar 2008, at 12:29, Chisel Wright wrote: On Tue, Mar 18, 2008 at 02:13:22PM +0200, Octavian Rasnita wrote: Do you have any idea why? None at all. Have you tried asking _them_? http://developer.yahoo.com/perl/ exists, is not linked. I've set things in motion both to fix that and to get some much needed love for the subsite itself. -- Mike Whitaker| Perl developer, writer, guitarist, photographer [EMAIL PROTECTED] | Board member, http://www.enlightenedperl.org/ Y!: tuxservers | Blog: http://perlent.blogspot.com/ IRC: Penfold | Yahoo! UK Ltd - internal CMS team ___ 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/ ___ 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] How do I access 'Catalysed' custom datasets?
On Tue, Mar 18, 2008 at 4:40 PM, Ian Sillitoe [EMAIL PROTECTED] wrote:
sub get_custom_resultset {
my ($from, $to) = @_;
my $result_source_name = ResultSetFrom${from}To${to};
my $result_source;
# check if we haven't already made this
if ( grep { $reps_source_name eq $_ } MySchema-sources() ) {
$result_source = MySchema-resultset($reps_source_name);
}
snip
Is this something to do with setting the __PACKAGE__-resultset_class (if
so, I'll take it to the dbi-class list)?
No, it's got to do with the fact that you seem to be confused about
what ResultSets and ResultSources are, they're very different things.
So, yes take it to the DBIC mailing list.
Side question - should I expect the
'catalysed' schema to behave exactly the same as the non-catalysed schema?
There's no such thing as a Catalysed Schema, what
Catalyst::Model::DBIC::Schema does is create accessor methods which
conveniently access the schema for you. Thus, $c-model('Schema::Foo')
actually calls $c-model('Schema')-schema-resultset('Foo') behind
the scenes.
--
edenc.vox.com
___
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] sqlite3
Hi All, is it mandatory to use sqlite3 in catalyst ? -- With Regards Gautam Gupta ___ 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] sqlite3
On 19 Mar 2008, at 12:39, gautam gupta wrote: Hi All, is it mandatory to use sqlite3 in catalyst ? -- Not by a long shot. Catalyst also doesn't talk to a database itself. And DBIx::Class to which I'm guessing you are talking about can use almost any database that perl can talk to. -ash___ 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] failed to install Catalyst::Plugin::Session::Store::FastMmap on strawberry perl
i failed to install Catalyst::Plugin::Session::Store::FastMmap on strawberry perl on windows here is the install attempt output basically i am installing all the modules necessary for trying the tutorial in catalyst docs this module is one those CPAN Terminal install Catalyst::Plugin::Session::Store::FastMmap Installing Catalyst::Plugin::Session::Store::FastMmap (0.05) Running [C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\bin\cpanp-run-perl.bat C:\DOCUME~1\Ali\APPLIC~1\CPANPL~1\ 510~1.0\build\Catalyst-Plugin-Session-Store-FastMmap-0.05\Makefile.PL ]... Warning: prerequisite Cache::FastMmap 1.13 not found. Writing Makefile for Catalyst::Plugin::Session::Store::FastMmap Module 'Catalyst::Plugin::Session::Store::FastMmap' requires 'Cache::FastMmap' to be installed If you don't wish to see this question anymore you can disable it by entering the following commands on the prompt: 's conf prereqs 1; s save' Should I install this module? [Y/n]: y Running [C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\bin\cpanp-run-perl.bat C:\DOCUME~1\Ali\APPLIC~1\CPANPL~1\ 510~1.0\build\Cache-FastMmap-1.25\Makefile.PL ]... Writing Makefile for Cache::FastMmap::CImpl Writing Makefile for Cache::FastMmap [ERROR] MAKE failed: Bad file descriptor [ERROR] Unable to create a new distribution object for 'Cache::FastMmap' -- cannot continue [ERROR] Failed to install 'Cache::FastMmap' as prerequisite for 'Catalyst::Plugin::Session::Store::FastMmap' [ERROR] Unable to satisfy prerequisites for 'Catalyst::Plugin::Session::Store::FastMmap' -- aborting install [ERROR] Unable to create a new distribution object for 'Catalyst::Plugin::Session::Store::FastMmap' -- cannot continue *** Install log written to: C:\Documents and Settings\Ali\Application Data\.cpanplus\install-logs\Catalyst-Plugin-Session-Store-FastMmap-0.05-1 205933004.log Error installing 'Catalyst::Plugin::Session::Store::FastMmap' Problem installing one or more modules *** You can view the complete error buffer by pressing 'p' *** CPAN Terminal p [MSG] [Wed Mar 19 15:23:19 2008] Module 'Catalyst::Plugin::Session::Store::FastMmap' requires 'Cache::FastMmap' version '1.13' to be installed [HISTORY] [Wed Mar 19 15:23:21 2008] Should I install this module? [Y/n]: y [ERROR] [Wed Mar 19 15:23:24 2008] MAKE failed: Bad file descriptor [ERROR] [Wed Mar 19 15:23:24 2008] Unable to create a new distribution object for 'Cache::FastMmap' -- cannot continue [ERROR] [Wed Mar 19 15:23:24 2008] Failed to install 'Cache::FastMmap' as prerequisite for 'Catalyst::Plugin::Session::S tore::FastMmap' [ERROR] [Wed Mar 19 15:23:24 2008] Unable to satisfy prerequisites for 'Catalyst::Plugin::Session::Store::FastMmap' -- a borting install [ERROR] [Wed Mar 19 15:23:24 2008] Unable to create a new distribution object for 'Catalyst::Plugin::Session::Store::Fas tMmap' -- cannot continue CPAN Terminal ___ 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] Patch for Catalyst::Plugin::Unicode::Encoding
On Wed, Mar 19, 2008 at 12:36:42AM -0500, Jonathan Rockway wrote:
* On Wed, Mar 19 2008, Jonathan Rockway wrote:
We should not need to check the flag. The incoming data should be
encoded. Then we should decode it. Then we should not try to decode it
again.
A key thing I forgot to mention is that is_utf8 doesn't mean we tried
to decode this already. It means that the internal representation of
the string is utf8.
Please don't say that. ;)
I think the fact that people know that Perl's *internal* encoding is
utf8 causes a lot of confusion. I wish is_utf8 was aliased as
is_decoded or is_characters and all we knew was that Perl uses
some kind of hidden internal character representation.
This is an important plugin, and it is often cited as something to
use. I'd argue that it should be part of Catalyst core and not a
plugin -- when do we not work with octets externally and characters
internally?
I think there's a number of problems with the plugin:
To be clear, the problem I posted about was the plugin *decoding*
already decoded content. If Perl sees the utf8 flag is already
set it will die with:
Cannot decode string with wide characters at ...
But, you ask, why would the plugin see already decoded content?
This can happen if the body was parsed with, for example, Expat or
XML::LibXML -- or there's some other custom body parser that needs to
work in decoded characters before this plugin runs.
So, it's very possible that the plugin would see already decoded
content and thus should not attempt to decode again.
Unless someone does something stupid and forces the utf8 flag true,
the utf8 flag indicates that the content has been decoded. That's why
it makes perfect sense to test it before decoding to avoid the error.
True, the utf8 flag does not mean we have non-ascii or wide
characters.
$ perl -MEncode -wle \
'print utf8::is_utf8( Encode::decode_utf8( foo ))
? Is utf8\n
: Is not utf8\n'
Is utf8
But it does mean we don't have to call decode again.
Even if decoding ascii-only chars as utf8 did NOT set the utf8 flag
true then decoding as utf8 again is not a problem (thanks to ascii
mapping to utf8).
Testing is the utf8 flag before decoding is the fix.
Here's another thing this plugin does incorrectly. The
current code is:
sub prepare_parameters {
my $c = shift;
$c-NEXT::prepare_parameters;
for my $value ( values %{ $c-request-{parameters} } ) {
[...]
It should be decoding *body_parameters*.
In other words, the result of that code above is:
length $c-req-parameters-{foo}
!= length $c-req-body_parameters-{foo}.
(or one parameter is utf8-flagged characters and one is a byte
string).
So, the fix is to override prepare_body_parameters to decode the
body params then $c-engine-prepare_parameter will merge the decoded
body params with the query params:
sub prepare_body_parameters {
my $c = shift;
# Read in the body params via the engine
$c-NEXT::prepare_body_parameters;
for my $value ( values %{ $c-request-body_parameters } ) {
# This breaks decoding if a param is a hash
# and Data::Visitor will return hash *keys* so that's no help
next if ref $value ref $value ne 'ARRAY';
for ( ref( $value ) ? @{$value} : $value ) {
# Don't decode if already decoded.
next if Encode::is_utf8( $_ );
$_ = decode_utf8( $_, $CHECK );
}
}
return;
}
Now, the query parameters need fixing in the same way.
Where the code to decode body and query parameters should go is
debatable. In some ways I think it should be in the Engine as that's
what is bringing the data into the application.
Maybe the decoding could happen in Engine's prepare_parameters as it's
looking at both the body and query params -- but that runs the risk of
something using the query params before they are decoded.
Finally, the plugin does this:
unless ( $c-response-content_type =~ /^text|xml$|javascript$/ ) {
return $c-NEXT::finalize;
}
unless ( Encode::is_utf8( $c-response-body ) ) {
return $c-NEXT::finalize;
}
$c-response-body( $c-encoding-encode( $c-response-body, $CHECK ) );
That's a bit less clear if that's correct or not. The is_utf8 does
serve a purpose, but I think it's implemented wrong.
Here's an example where that might be a fix: Your normal encoding is
utf8, but you also return XML and you have a client that, for some
reason, insists on a different encoding. So you encode the body
(clearing the utf8 flag) before the plugin sees the body. So the test
of is_utf8 above will keep from encoding the already-encoded byte
string.
Of course, what should happen is the output encoding should be
determined by looking at the Accept-Charset and maybe send a 406 if
can't find a suitable encoding.
--
Bill Moseley
[EMAIL PROTECTED]
___
List:
[Catalyst] Behaviour of Catalyst::Plugin::Authentication
Hi,
I stumbled upon a feature of the Authentication Plugin today
(Yes I was the guy who used Ash's cardboard cutout programmer service
earlier today on #catalyst, so thanks again, Ash ;-)
My configuration was something like this:
authentication:
default_realm: users
realms:
users:
credential:
class: Password
user_field: login
password_field: password
password_type: clear
store:
class: DBIx::Class
user_class: MyAppDB::Users
role_class: MyAppDB::Roles
role_field: title
role_relation: user_roles
user_role_user_field: user_id
but the $userinfo hash I passed to the authenticate() method looked
like this
my $userinfo = { username = $login, password = $password}
Thus, Catalyst logged in the first user in the MyAppDB::Users table if I
provided the correct password regardless of what I supplied as a login
(ok, the latter is obvious).
Does the plugin try to DWIM by using the first user it happens to
stumble upon and using his primary key as the login field? This is what
I suspect because the (test-)user in question happened to have 1 as
his primary key as well as in the 'login'-column.
Maybe this is because of my limited idea of what $userinfo can be, but
wouldn't a warning be suitable in such a case?
Thanks,
Jochen
___
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] Memory leak under FastCGI?
We have a Catalyst app that I recently (about a month ago) converted from running under mod_fcgid to external under mod_fastcgi and it appears to be leaking memory. There are 2 application backends and they both suffered oom-killer events within six minutes of one another yesterday and one of them again this morning after a cron job ran that experienced some deep recursion calls. Both backends were running out of PARs when the first OOM events occurred. To eliminate the PAR setup itself as a cause, I started one of the backends by directly invoking myapp_fastcgi.pla and its memory behavior is the same, so I'm pretty confident the invocation via PAR is not a cause. I also checked my versions of CGI::FormBuilder to ensure I was up to 3.501 and these all checked out. I have not yet determined if the conversion from mod_fcgid to mod_fastcgi external is when the RAM usage started climbing - still awaiting system reports - but, there haven't been an substantial changes to the app since then that I would consider potential causes of a memory leak. I'm guessing it's been there for a while, but it's only now evident because the app instances were getting automatically recycled by mod_fcgid and now they're not. I'm hoping someone here might have some light to shine on common FastCGI memory leak issues. Is it generally an acceptable practice to just restart the external fastcgi process periodically to free its memory? Any input is greatly appreciated. v/r -matt pitts ___ 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] Behaviour of Catalyst::Plugin::Authentication
Jochen Luig wrote:
Hi,
I stumbled upon a feature of the Authentication Plugin today
(Yes I was the guy who used Ash's cardboard cutout programmer service
earlier today on #catalyst, so thanks again, Ash ;-)
My configuration was something like this:
authentication:
default_realm: users
realms:
users:
credential:
class: Password
user_field: login
password_field: password
password_type: clear
store:
class: DBIx::Class
user_class: MyAppDB::Users
role_class: MyAppDB::Roles
role_field: title
role_relation: user_roles
user_role_user_field: user_id
but the $userinfo hash I passed to the authenticate() method looked
like this
my $userinfo = { username = $login, password = $password}
Thus, Catalyst logged in the first user in the MyAppDB::Users table if I
provided the correct password regardless of what I supplied as a login
(ok, the latter is obvious).
Does the plugin try to DWIM by using the first user it happens to
stumble upon and using his primary key as the login field? This is what
I suspect because the (test-)user in question happened to have 1 as
his primary key as well as in the 'login'-column.
Maybe this is because of my limited idea of what $userinfo can be, but
wouldn't a warning be suitable in such a case?
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Alex.
___
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] [OT] Request for help
Hi everyone, First, let me apologize if you are seeing this twice as a result of the cross post. As some of you may know, apart from being a module developer and occasional presence of the lists and IRC, I am a student of Economics at Northeastern University. I am preparing the final research paper for my Senior Economics Seminar and I was hoping that those of you who have participated in open source hacking while employed could help me out by answering couple of short questions. This only applies to those of you who have either contributed, or paid someone to contribute to an OSS while on the clock. Please, please, please take 2 mins to answer (it's mostly one word answers) and send it back to [EMAIL PROTECTED] (don't reply to the list!) 1.) Name / alias, (last name optional) 2.) Company where development took place (optional) 3.) Were any of the contributions made simply to satisfy a license? (Yes, No) 4.) Were any releases, contributions made even though the license did not require you too? (yes, no) 5.) Was management, or your corporate environment receptive to participating in OSS? (yes, no) 6.) Why do you choose to participate in OSS? 7.) Do you feel there is an indirect return to contributing to OSS, and if so, what is it for you? 8.) Estimated value or (?:wo)?man-(?:months|days) of your yearly contributions ( optional ) Feel free to use your ohloh figures if you think they are accurate. Thank you so much to whoever can help! I need answers by Wednesday Mar 26 at the latest. I slacked off on my homework because I was too busy hacking on open source! If you know anyone else who wouldn't mind answering this please feel free to forward this. Remember, the more answers I get, the quicker I'll be able to resume helping the Moose + Catalyst effort. Thanks again, -- Guillermo Roditi (groditi) ___ 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] failed to install Catalyst::Plugin::Session::Store::FastMmap on strawberry perl
On 3/19/08, Ali M. [EMAIL PROTECTED] wrote: i failed to install Catalyst::Plugin::Session::Store::FastMmap on strawberry perl on windows Module 'Catalyst::Plugin::Session::Store::FastMmap' requires 'Cache::FastMmap' to be installed Cache::FastMmap doesn't work on windows. It uses mmap and fcntl which are non-existent on windows. -- Radek ___ 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] Behaviour of Catalyst::Plugin::Authentication
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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] Behaviour of Catalyst::Plugin::Authentication
Hi Jochen,
You are nearly there.
The DBIx::Class store interprets the authinfo hash (almost) exactly
like the condition argument to $resultset-search(); The 'almost'
bit is that it will filter out any columns that aren't actually in the
user class.
So - if you provide it with an authinfo hash that has no fields that
match the user class - what you get is:
$resultset-search(undef)-first;
Which will most likely return the first user in your table.
So yes... in the rather unlikely event that the passwords happen to
match, will get you logged in as that user.
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
Those who can make you believe absurdities can make you commit
atrocities. --Voltaire
___
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] Behaviour of Catalyst::Plugin::Authentication
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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] Behaviour of Catalyst::Plugin::Authentication
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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] Behaviour of Catalyst::Plugin::Authentication
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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] Behaviour of Catalyst::Plugin::Authentication
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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] Behaviour of Catalyst::Plugin::Authentication
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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] Behaviour of Catalyst::Plugin::Authentication
Sorry all. Mail client went crazy.
If you try to call authenticate with no valid fields from the user
class - it will throw an exception - as of the next release.
Jay
On Mar 19, 2008, at 2:44 PM, Jay K wrote:
Upon consideration - I've decided to throw an exception if you try to
always going to be an error and better to fail loudly than silently
pass auth, even if it is unlikely that the passwords will match.
I'll put this in the next release.
You can still accomplish an empty search if you really want to by
using the searchargs parameter...
Jay
On Mar 19, 2008, at 2:08 PM, Jochen Luig wrote:
Hi Alex,
It is A Feature. You've messed with parameters, username in
userinfo,
login in credential. my $userinfo = { login = $login, password =
$password} will cure.
Yes, I know. I found this out just as I was beginning to complain on
#catalyst. I just wanted to know if I interpreted the behaviour (the
primary key part) correctly and if my suggestion to issue a warning
in
such a case is off-base.
Best regards,
Jochen
___
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/
---
America will never be destroyed from the outside. If we falter and
lose our freedoms, it will be because we destroyed ourselves. --
Abraham Lincoln
___
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/
---
For most things, throwing yourself at the wall over and over is a
better way to improve than thinking hard about the wall and taking
pictures of it. -- D.Litwack
___
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/
