Re: [Catalyst] How to extend authentication to use other DB fields?
> I would like to extend my autentication to accept other fields:
> with $c->authenticate({ fileld1 => [..], field2 => [...], fieldd => [...] });
...
> Do I have to create my own Catalyst::Authentication::Credential plugin?
No, it already does that... per the docs:
The first, and most common, method is simple retrieval. As its
name implies simple
retrieval allows you to simply to provide the column => value
pairs that should be
used to locate the user in question. An example of this usage is below:
--
Evan Carroll
System Lord of the Internets
___
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] How to extend authentication to use other DB fields?
Hello,
I am currently using the simple password authentnication:
__PACKAGE__->config->{'Plugin::Authentication'} = {
default => {
class => 'DBIx::SimpleDB', #
user_model => 'DB::User',
password_type => 'self_check',
},
};
with $c->authenticate({ username => [..], password => [...] });
I would like to extend my autentication to accept other fields:
with $c->authenticate({ fileld1 => [..], field2 => [...], fieldd => [...] });
Do I have to create my own Catalyst::Authentication::Credential plugin?
Thank you
Julien
___
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] Security issues and rude comments
While I can understand how some folks have issues with others, can we try to state them in a more positive manner? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ 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] Security issue with hashed passwords in C:P:A:Password
> While my opinion of you is not favorable, I do believe that we should > always look at reports without seeing who filed them and react > accordingly. duly noted. > The option for 'hashed' does what you are talking about, and the > documentation clearly lists the differences here. Yes, well I don't see this "clearly" communicated here. In fact, for me, I don't see the "difference" at all -- so maybe you can rub this off as a doc bug. I've never heard of Crypt::SaltedHash prior to today, and had no idea of what it does. However, I'm very familiar with salts, and hashing. I also see little reason to indicate 'salted_hash', should be chosen over 'hashed', w/ salted attributes. When I was reading the docs, I saw "Digest", and mention of salts, and figured that was what I as looking for. This could have been my error. > I'm more of the mind that this is a non-issue, but could easily lead > people astray into doing something that they do not want to do. If > there is a problem with the way the salts are handled, that would be a > problem in Crypt::SaltedHash. I disagree, reviewing Crypt::SaltedHash, which I wasn't speaking about: it simply serializes the salts and hash(salt . password). Here, I just store in the DB the salt un-serialized with the hash of the salt and the password. I'm not sure my approach is better, or worse; but, I've been doing it for a long time and it is a wide spread practice. After, all the only thing we're doing with salts is stopping a rainbow table attack. Like, t0m I've patched this. In my patch I add two fields which read the user-object. So long as the salt isn't global, but user-specific it will work. Salting a pkid certainly works, and so does storing a random number. Arguably, there are benefits to both sides, and both should accomplish the task effectively. I personally feel, as if someone confused my method (not, that I did it first) when they implemented this pre_salt in config stuff... I'd guess I'm not the only one that has been confused by this. People who use salts the way I've always done them are very likely to read into it and think that the 'hashed' is the best match for them. > Your bug report does seem to imply it would be a problem with > Crypt::SaltedHash, though, which is why without a more thorough > glance, you look like you are wholly mistaken. I don't think anything implies Crypt::SaltedHash in my bug report -- if it did it was a miscommunication. Sorry, I'm not speaking about it at all. Furthermore, after reviewing it seems like a perfectly good solution however different and less-portable it is. Thanks for the reply. -- Evan Carroll System Lord of the Internets http://www.evancarroll.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/
Re: [Catalyst] Security issue with hashed passwords in C:P:A:Password
On Wed, Mar 24, 2010 at 11:13 AM, Evan Carroll wrote:
>> It would be if anything you said were true; fortunately it's not, and both
>> available methods of doing salted passwords with
>> Catalyst::Plugin::Authentication do salt entirely the correct way.
>>
>> Your unncecessary and condescending lectures are, however, greatly
>> appreciated
>> as usual.
>
> While you're probably doubting your whole statement about salts being
> implemented "entirely the correct way," I just wanted to indulge you
> with one more lecture. I feel the need to call you out and cross-post
> your repsonse on rt for the historical mailing-list record:
>
> I have no idea what distribution you intended to file this bug against,
> but it's obviously not the one you *did* file against, which does
> nothing even vaguely resembling reading salt from a config file.
>
> To which I responded:
>
> http://search.cpan.org/src/FLORA/Catalyst-Plugin-Authentication-
> 0.10016/lib/Catalyst/Authentication/Credential/Password.pm
>
> I think I've got the right one...
>
> P.S. stop being an asshole, thanks.
>
> along with the code:
>
> Just to save some insincere discourse and further boring name calling:
>
> $d->add( $self->_config->{'password_pre_salt'} || '' );
> $d->add($password);
> $d->add( $self->_config->{'password_post_salt'} || '' );
>
> I have a disconnect sometimes when I see "Andrew Rodland," instead of
> "hobbs" but your unwavering hostility is certainly noticed. Rather
> than give the bug report a fair evaluation you deny it without reason.
> Like most religions, yours has an convenient indicator: "if anything
> you said were true; fortunately it's not." Good, concise illogical ad
> hominum not grounded in reality, and totally without merit as to the
> bug report.
>
While my opinion of you is not favorable, I do believe that we should
always look at reports without seeing who filed them and react
accordingly.
In this case, though, the 'salted_hash' option defers all salting to
Crypt::SaltedHash.
The option for 'hashed' does what you are talking about, and the
documentation clearly lists the differences here.
I'm more of the mind that this is a non-issue, but could easily lead
people astray into doing something that they do not want to do. If
there is a problem with the way the salts are handled, that would be a
problem in Crypt::SaltedHash.
Your bug report does seem to imply it would be a problem with
Crypt::SaltedHash, though, which is why without a more thorough
glance, you look like you are wholly mistaken.
-J
___
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] Security issue with hashed passwords in C:P:A:Password
> It would be if anything you said were true; fortunately it's not, and both
> available methods of doing salted passwords with
> Catalyst::Plugin::Authentication do salt entirely the correct way.
>
> Your unncecessary and condescending lectures are, however, greatly appreciated
> as usual.
While you're probably doubting your whole statement about salts being
implemented "entirely the correct way," I just wanted to indulge you
with one more lecture. I feel the need to call you out and cross-post
your repsonse on rt for the historical mailing-list record:
I have no idea what distribution you intended to file this bug against,
but it's obviously not the one you *did* file against, which does
nothing even vaguely resembling reading salt from a config file.
To which I responded:
http://search.cpan.org/src/FLORA/Catalyst-Plugin-Authentication-
0.10016/lib/Catalyst/Authentication/Credential/Password.pm
I think I've got the right one...
P.S. stop being an asshole, thanks.
along with the code:
Just to save some insincere discourse and further boring name calling:
$d->add( $self->_config->{'password_pre_salt'} || '' );
$d->add($password);
$d->add( $self->_config->{'password_post_salt'} || '' );
I have a disconnect sometimes when I see "Andrew Rodland," instead of
"hobbs" but your unwavering hostility is certainly noticed. Rather
than give the bug report a fair evaluation you deny it without reason.
Like most religions, yours has an convenient indicator: "if anything
you said were true; fortunately it's not." Good, concise illogical ad
hominum not grounded in reality, and totally without merit as to the
bug report.
--
Evan Carroll
System Lord of the Internets
http://www.evancarroll.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/
Re: [Catalyst] Security issue with hashed passwords in C:P:A:Password
> I'll still chase this up tonight so that we're all clear if there is a > potential (but very limited) issue or not :) The issue here is the implementation of salt gives you a false sense of security. If you aren't worried about rainbow attacks simply don't use salt at all. It should be noted that any global salt will at least lessen the chance of unsalted rainbow tables from being used (such as those downloaded from torrents), but this is marginal. With that said, I've got the rewritten, moosified, copy up with doc patches, passing tests, and a working implementation of password_pre_salt_field, and password_post_salt_field, you can find it at: http://github.com/EvanCarroll/Catalyst-Plugin-Authentication/blob/master/lib/Catalyst/Authentication/Credential/Password.pm -- Evan Carroll System Lord of the Internets http://www.evancarroll.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/
Re: [Catalyst] Security issue with hashed passwords in C:P:A:Password
> P.S. Yes, I appreciate that the attack surface is fairly limited here, bit I > feel the point still holds. I disagree, I wouldn't want to extend my fame into publicizing a massive security vulnerability. I think this one stems from a misunderstanding of salting. I've forked C:P:A on gitpan and I'll probably port some (or all) of it to Moose along with my own fix to this soonish. > P.P.S. I expect to be uploading a fix this in the next 24-48 hours for > anyone who concerned that evil people in possession of their application > configuration are generating the relevant rainbow tables right now... -- Evan Carroll System Lord of the Internets ___ 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] Security issue with hashed passwords in C:P:A:Password
Tomas Doran wrote: P.P.S. I expect to be uploading a fix this in the next 24-48 hours for anyone who concerned that evil people in possession of their application configuration are generating the relevant rainbow tables right now... Well, having read the other followups (bah, my home internet was broken last night so I wrote a pile of mail without seeing replies), then if there is actually an issue is somewhat in doubt here... I'll still chase this up tonight so that we're all clear if there is a potential (but very limited) issue or not :) 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] Slow Makefile.PL
On 23 Mar 2010, at 21:52, Wade Stuart wrote: > > The other option is to wait (up to 2 minutes) for RAM to write to disk and > the sleep light to slow blink before moving your lappy; I am just too > impatient. See also http://www.jinx.de/SmartSleep.html ___ 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 jQuery with development server
And what is your question? :)
PS: anyway, this is not a jQuery list...
2010/3/24 Colin Brizell :
> I have the following markup in a template list.tt2 file
>
>
>
>
>
>
>
>
>
> title="Remove" />
>
>
>
>
>
>
>
> When I clink on the image the first two alerts are displayed but the third
> on isn’t and
>
> The “list function in the Question.pm Controller is called and the page is
> refreshed.
>
>
>
> If I remove the following jQuery code:-
>
>
>
> $('#row_1_1').remove();
>
>
>
> The event is not propagated
>
> ___
> 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/
>
>
--
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)
___
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] Using jQuery with development server
I have the following markup in a template list.tt2 file
When I clink on the image the first two alerts are displayed but the third on
isn't and
The "list function in the Question.pm Controller is called and the page is
refreshed.
If I remove the following jQuery code:-
$('#row_1_1').remove();
The event is not propagated
___
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] Security issue with hashed passwords in C:P:A:Password
On 23 Mar 2010, at 20:17, Evan Carroll wrote: This is broken implementation. Hard coding salt in a config file only protects you from a rainbow table without that salt. It still doesn't solve the problem of cached hashings. Thanks for the responsible disclosure of a potential security vulnerability. I had an entire 4 mins after the bug report in which to make a fix available :) Cheers t0m P.S. Yes, I appreciate that the attack surface is fairly limited here, bit I feel the point still holds. P.P.S. I expect to be uploading a fix this in the next 24-48 hours for anyone who concerned that evil people in possession of their application configuration are generating the relevant rainbow tables right now... ___ 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] application broke once installed under other than the web root directory
On 21 Mar 2010, at 17:18, Charles wrote: I have finished development of my app using the built in server in the scripts dir. I have installed it and configured apache to let it run under http://myurl.com/myapp . The Root.pm index controller get's called and works ( fetches db table data and returns via TT ) when I visit http://myurl.com/myapp. And the debug output is here: Heya. Can you give us: 1) The entire app startup debug sequence 2) More details about the environment (which mod_perl version, which apache version, perl -V etc) 3) The 'base' attribute you get from the debug screen when you hit the root page? (For you, http://myurl.com/myapp?dump_info=1 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] Configuring individual models via config file with DBIx::Class:Schema
On 22 Mar 2010, at 19:15, Alan Schwartz wrote:
I have an application using DBIx::Class::Schema. In the application
config file, I have:
schema_class MyApp::Schema
...various necessary stuff here...
someattribute value
anotherattribute anothervalue
The first two of these blocks do what I expect -- my models
get build from the Schema/Result files, I get connections, etc.
And in Controller/One.pm, I can access $self->{someattribute}
To start with, don't do that!
Make a _real_ attribute, e.g.
has someattribute => ( is => 'ro' );
and then call the proper accessor, e.g.
$self->someattribute;
But I can't for the life of my figure out how I can get
anotherattribute
into the config for an individual model based on the schema.
The problem you are having is that your mental model is broken. Your
entire DBIC schema is _one_ model. There is not one model per table in
your DB.
The DBIC model does some trickery as a shortcut for you - so that you
can say $c->model('DB::Person') rather than $c->model('DB')-
>resultset('Person').. However everything under the top level model
class is owned and controlled by that class, it's not a separate model
and so the normal rules don't really apply. :(
That is, I'd like methods in DB::Two objects to have access
to $self->{anotherattribute}
In addition to the above, I have tried:
* Variations on the config block (,
,
, even )
* Putting that block within the block, again with all
those variations
If you just put the attribute directly on your Schema (rather than a
specific resultset), then what you want will (I think, off the top of
my head having not looked) it'll all just work.
You can trivially get back to the schema from the resultset, and (if
it's more convienient) add a delegate method in the resultset to get
the attribute from the schema.
I haven't found the answer so far in searching this mailing list
or the web. Is this possible? What am I missing here?
Thanks in advance!
Hop on irc into #catalyst or #dbix-class and people will be extremely
happy to lead you through sorting out what you want to achieve (whilst
also being architecturally correct) if you're prepared to write a
sentence or two (perhaps even an entire paragraph?) for the docs to
explain this to the next person who comes along?
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] Slow Makefile.PL
On 23 Mar 2010, at 21:52, Wade Stuart wrote: The other option is to wait (up to 2 minutes) for RAM to write to disk and the sleep light to slow blink before moving your lappy; I am just too impatient. Or just shell out for the SSD option. :) 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] Re: Security issue with hashed passwords in C:P:A:Password
> Crypt::SaltHash makes the salt a function of the username, I haven't > looked too much into the implementation but it certainly isn't the > normal method of salting -- though it most probably helps some level. > It's not. Crypt::SaltedHash doesn't know about the username. cheers, mo ___ 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/
