Re: [Catalyst] Catalyst site design drafts feedback thread
Overall I have the same criticism for all of the designs. None of them really pass the first glance test. Designs: (1) http://www.browsing.co.uk/cat The contrast is overwhelming. Everything has a similar level of contrast and thus importance, and there is no real indication of where the user should go. My eyes just wander around this page searching desperately for something to land on, and I always land on the cupcake. While I like cupcakes, I always wind up wanting to leave the computer and forage for cupcakes in the cupboard. Which is not what we want people doing when they visit the site to learn about catalyst. (2) http://agaton.scsys.co.uk/~matthewt/catsite/cat_mock_web_001.png A bit better, though I'm not fond of the color scheme. My eyes land on the crop circle, which at least gives me an imprint of the cat logo. That said, the navigational links don't call attention to themselves, so I wind up relying on web navigation habit - rolling around the page with my eyes to find something that looks like a list.Also - there is too much text on the main page, which makes me want to find another page that is friendlier and doesn't present me with text overload right away. (3) http://ion0.com/hx/cat/new-version-2-26.jpg I like the header and navigational links here - because the contrast calls attention to them - but the dark area at the top of the content box is a bit too deep imho and makes the page feel weird / top heavy to me. Without text content it's hard to judge this layout the same way as the others. (4) http://ion0.com/hx/cat/catalystSiteDesign3.jpg Of the two from Scott, I prefer 3. (5) http://agaton.scsys.co.uk/~matthewt/catsite/catsite-Penfold.pdf This design pops more, there is no trouble finding the nav links. The font and color scheme, though, make it somewhat hard to look at for an extended period of time. A slightly more subdued header color I think would make me like this one more. The text is bigger, that's good, there is still too much of it for a landing page. I like the layout for a content page, though. 6) http://www.funkreich.de/catalystorg.png Overall, my current favorite. Definitely in terms of spacing. I'm not fond of the orange, and I don't know that the 'download' link really makes sense. (Maybe replace with a 'learn more?') What I like about this design, though, is that it's absolutely clear what you are here for. The nav links are separated from the rest of the site design enough to make them prominent. The fonts are good and the text is not overwhelming. My only real criticism aside from the orange is that it'd be nice to have some clear 'getting started' / 'more about catalyst' type links in a prominent position.The links at the bottom are too hidden. In my browsers default size, they are just barely above the fold and I registered them in the same way as I do the copyright notice on most sites... in other words not at all. Definitely want to get the three main links - 'Get Started', 'Get Help', 'Get Involved' up into the white area and made more prominent. So there's my two cents. Hope it helps, Jay On Jun 11, 2008, at 1:54 PM, Matt S Trout wrote: (1) http://www.browsing.co.uk/cat Mark Keating: (2) http://agaton.scsys.co.uk/~matthewt/catsite/cat_mock_web_001.png Scott Ladzinski: (3) http://ion0.com/hx/cat/new-version-2-26.jpg (4) http://ion0.com/hx/cat/catalystSiteDesign3.jpg Mike Whitaker: (5) http://agaton.scsys.co.uk/~matthewt/catsite/catsite-Penfold.pdf Gentlement, start your feedback engines. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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] New credential -- Catalyst::Authentication::Credential::OpenID
Hi Ashley,
Sorry for the delay, It sounds quite interesting. Are you working off
of the auth module in svn at the moment, or the released version. I
ask because there are changes in svn that might make it easier to
implement. I'm in the process of documenting those changes for a
release soon. Namely, the realm has much more control (more hook
points) in the auth process - might be useful.
Anyway - let me know if I can help in any way.
Jay
On Apr 5, 2008, at 10:11 PM, Ashley wrote:
On Apr 5, 2008, at 8:44 PM, J. Shirley wrote:
On Wed, Apr 2, 2008 at 9:38 PM, Ashley <[EMAIL PROTECTED]> wrote:
Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].
I think I have a working modernized (to the current bleeding edge
of the
Auth system) OpenID Credential package:
Catalyst::Authentication::Credential::OpenID. Before I work on
docs and
trying to making it tested and bomb-proof I want to check with all
y'all.
It's based on the second generation
Catalyst::Plugin::Authentication::Credential::OpenID from
Tatsuhiko Miyagawa
and all the new stuff from Jay Kuri.
So instead of
$c->authenticate_openid()
you have realm based auth
$c->authenticate({ openid_identifier => $claimed_uri }, "openid")
This sounds like the right direction to me. I'm eager to see the new
work, as well. Do you have a dev package available?
Great. I worked on it a bunch today and got a working test app with
it running a provider and a consumer along with some plain text
inline Auth so it can test itself. I managed to use some of JRock's
test stuff + some of JK's to write a live test that I *think* is
okay. It's difficult to know because the test server has to run with
forking so it can answer its own requests but it's passing in my env
on OS X at least. It's minimal but there is a working OpenID server
example in the t/TestApp code.
I'm trying to do some reasonable POD right now and I was hoping to
get a slightly messy 0.01 on the CPAN tonight (missing the OpenID
store class which I'd really like to have but that's another day+ to
write and test which might push it off a week or more). I have my
own svn server but since it's just me, it's messy with poor revision
messages and I check in broken stuff so I can get it between my
machines... that said, if you can't wait or I'm too slow:
http://dev.perlperl.com/cpan/trunk/CA-OpenID/
(that should be open for checkouts; I just flipped it to public).
Also, if you need proper commit bits to the main Catalyst repos
please let me know
and I'll get that sorted out for you.
I would love that. If nothing else, I'd be glad to tackle typo/small-
fish bugs and help update some of the document drift in
authentication stuff.
I'm getting ready to start working on another OpenID consumer
application, and would like to use your work.
I hope you do and please if any room for improvement jumps out at
you, don't be shy. I worked a bunch with OpenID last year on a
contract but I'm no guru with it.
-Ashley
___
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
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/
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
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] Catalyst and Shibboleth authentication
On Mar 17, 2008, at 4:40 PM, Alex Povolotsky wrote:
Jay K wrote:
That page is slightly incorrect.
In C::A::Store::Null -based class, apparently $storeclass-
>can('find_user') returns 0 (called from
C::A::Authentication::Realm.pm line 85) so Realm tries to construct
find_user by itself, without success.
Yes. Null does not implement find_user - you have to. Which is
why
the wiki page says subclass and add find_user.
Hmm... I guess you should read Null.pm, especially lines 29-32.
Ah. I see that you are correct. A
Catalyst::Authentication::Store::Null object should return true to
can('find_user') I'd be interested in seeing a test where that fails.
For SSO - you can hook at any of those points. The store is the
easiest, really - because Credential::Password has a 'passthrough'
mode by telling it password_type='none' - effectively delegating the
entire auth process cleanly to the store's find_user method. Since
you will probably need to provide some type of user information -
overriding the store gives you the ideal spot to handle both at the
same time.
Well, I still think that SSO is for CREDENTIAL VALIDATION, so we
need to override Credential.
Actually, I've done an extremly simple SSO (but it works good
enough!) and store authenticated users in DBIx::Class, and happy
with it :)
Surely one could override Realm, or Catalyst itself, or rewrite
Catalyst from scratch, but I've explained my position.
As I mention in my previous post - It really depends on the complexity
of your SSO system and what it grants access to in your app. It could
also very easily be considered user retrieval - in which case a store
could be considered more appropriate.
My point is simply that I built the Auth module to allow the most
flexibility for customization without the need to 'rewrite Catalyst
from scratch' as you put it. Any of the hook points I mentioned can
be appropriate, and indeed for an SSO such as OpenID, which is much
more complex than validating a hash in a cookie - overriding at $realm-
>authenticate() may be the best option.
Jay
---
"May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples."
- 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] Catalyst and Shibboleth authentication
That page is slightly incorrect.
In C::A::Store::Null -based class, apparently $storeclass-
>can('find_user') returns 0 (called from
C::A::Authentication::Realm.pm line 85) so Realm tries to construct
find_user by itself, without success.
Yes. Null does not implement find_user - you have to. Which is why
the wiki page says subclass and add find_user.
I wonder why wiki suggests to override storage; overriding
credentials should be much more reasonable.
Either is fine, actually. The execution path for authentication is
by default:
$c->authenticate() --> $realm->authenticate() --> $credential-
>authenticate() --> $store->find_user()
For SSO - you can hook at any of those points. The store is the
easiest, really - because Credential::Password has a 'passthrough'
mode by telling it password_type='none' - effectively delegating the
entire auth process cleanly to the store's find_user method. Since
you will probably need to provide some type of user information -
overriding the store gives you the ideal spot to handle both at the
same time.
It really depends greatly on how complicated your SSO system is.
Jay
---
"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] bypassing password authentication
tsk tsk. Using internal methods. ;-)
There's actually a much easier way to do this.
Step 1: Create a duplicate realm to your normal realm. Call it
'passwordless' or something.
Only instead of password_type => 'crypted' or whatever - set
password_type => 'none'.
Step 2: use the passwordless realm.
Step 3: There is no step 3.
Just make your auth call look like this - IE leave out the password
altogether, and use the passwordless realm.
$c->authenticate({ username => $usernamevariable }, 'passwordless');
*poof* passwordless authentication.
Just for the record - just because you can doesn't mean you should.
Don't take this as a recommendation, more of a 'how to if you are
really determined to do that.'
Jay
On Mar 11, 2008, at 12:37 PM, Ash Berlin wrote:
On 11 Mar 2008, at 18:33, Jim Spath wrote:
I'm currently using password authentication in a Catalyst app, but
would like to implement a way to log in as a particular user,
without knowing the password. (Please don't respond with "don't do
this"... I'm aware of the security ramifications of this kind of
functionality).
I'll already have all the information on the user, except for their
password, since we hash the password before storing it.
The end goal would be to have an authenticated session.
Thanks!
- Jim
*WARNING* might not work with the new auth framework. But here's
some code:
sub login_as : Local Args(1) {
my ($self, $c, $user_id) = @_;
$c->res->redirect($c->uri_for()) if $user_id =~ /\D/;
my $user = $c->model('DBIC::User')->find($user_id);
if ($user) {
$c->set_authenticated($c->find_user({ id => $user->email}));
$c->flash(message => "Logged in as @{[$user->email]}");
}
return $c->res->redirect('/');
}
___
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/
Re: [Catalyst] On authentication again
Hi Byron,
Actually, it depends largely on what version of the module you are
using.
If you are up to date - the 'Plugin::Authentication' naming is the
proper way to do it (it now follows the configuration naming rules) -
but this is a relatively recent change and the 'authentication' naming
is still referred to as a backup naming if the 'proper' naming is not
found.
Jay
On Mar 6, 2008, at 11:03 AM, Byron Young wrote:
Alex Povolotsky wrote:
I even don't understand what __PACKAGE__->config-> I should use -
{'Plugin::Authentication'}, {authentication}
or{authentication}{dbic}.
Docs are unclear.
Alex,
It should be {authentication}. Here's mine:
authentication:
default_realm: database
realms:
database:
credential:
class: Password
password_field: password
password_type: hashed
password_hash_type: SHA-1
store:
class: DBIx::Class
user_class: DB::Users
id_field: username
role_field: name
role_relation: roles
Hope that helps
Byron
___
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/
---
"May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples."
- 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] installing authentication modules
You are correct. Catalyst::Authentication::Store::DBIx::Class is correct. There are older modules that use the Plugin style naming - and Catalyst will attempt to load using the Plugin naming if it can't find the Catalyst::Authentication:: version. If you look at your logs you should see a warning regarding 'trying Deprecated naming' or something similar. I've added a more detailed message for this situation. It will be present in the next release. Jay On Mar 5, 2008, at 8:33 AM, Andreas Marienborg wrote: On Mar 4, 2008, at 4:01 PM, rahed wrote: Hi, I installed Catalyst and other additional modules. When starting myapp_fastcgi.pl I got the message: Can't locate Catalyst/Plugin/Authentication/Store/DBIx/Class in @INC. Actually I had to install Catalyst::Authentication::Store::DBIx::Class to fix it. I am a bit perplexed by the docs about authentication/authorization modules - which should be installed and which are deprecated. I think its like this. Catalyst::Plugin::Authentication is good. Anything else (Store, Credential etc) should be without Plugin::-part and you should only load the Catalyst::Plugin::Authentication from your application and then the rest is loaded based on the config - andreas ___ 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] Authentic/Session modules problem
Hi Dermot,
The Plugin::Session::Store::FastMmap module provides the essential
glue between the session system and the actual fastmmap system.
The Plugin::Session::FastMmap module is old and probably doesn't get
along with the current session engine.
Use the Store module instead and see if it resolves your issues.
Jay
On Feb 29, 2008, at 6:03 AM, Dermot wrote:
Hi,
I am working with the tutorials, at the authentication part, and
have hit a snag.
I've add the following to my package
Authentication
Authentication::Store::DBIC
Authentication::Credential::Password
Session
#Session::Store::FastMmap
Session::FastMmap
Session::State::Cookie
I had to remove the 'Store' from the path to FastMmap because my
FastMmap.pm lives here:
~/Catalyst/Plugin/Session/FastMmap.pm
~/auto/Catalyst/Plugin/Session/FastMmap
However whenever I try to restart MyApp with Session::FastMmap
enabled I get:
Can't use string ("MyApp") as a HASH ref while "strict refs" in use
at /usr/lib/perl5/site_perl/5.8.8/Class/Accessor/Fast.pm line 39.
If I remark FastMmap out from the MyApp.pm and then login I get:
[debug] Created session "f19a97c4db250699be73e3250bdba8b1e8a0210e"
[debug] Successfully authenticated user 'dpaikkos'.
[error] Caught exception in engine "Can't locate object method
"store_session_data" via package "Images" at /usr/lib/perl5/
site_perl/5.8.8/Catalyst/Plugin/Session.pm line 136.
So I guess FastMmap is essential to the authentication and session
management.
Can anyone help me work out what's going on?
Thanx,
Dp.
PS: Is there a searchable mailing list archive?
___
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] Issue with C::A::Store::LDAP and C::A::Credential::Password
Follow up for the list.
The first issue here is that Credential::Password expects you to pass
the password field name to authenticate, not just 'password'. So if
your password_field is 'userPassword', as it is below, your
authenticate call should reflect that. The same goes for the user id
field. So the authenticate call for the config below should actually
be:
$c->authenticate({ uid => $username,
userPassword => $password });
I've added a note to the C::P::Auth docs to call that out more clearly.
Jay
On Feb 27, 2008, at 11:42 AM, Richardson, Matthew wrote:
I am attempting to authenticate against the LDAP server used for our
Unix authentication environment. A use entry looks like:
dn: uid=uname,ou=People,dc=company,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: uname
sn: LastName
givenName: FirstName
cn: uname
userPassword: {crypt}sFBVlCCFXromo
loginShell: /bin/csh
uidNumber: 7904
gidNumber: 6062
homeDirectory: /user/uname
gecos: FirstName LastName
mail: [EMAIL PROTECTED]
displayName: LastName, FirstName
telephoneNumber: 555
I have configure authentication using:
use Catalyst qw/-Debug ConfigLoader Static::Simple
Session
Session::State::Cookie
Session::Store::FastMmap
Authentication/;
__PACKAGE__->config(
'authentication' => {
default_realm => "ldap",
realms => {
ldap => {
credential => {
class => "Password",
password_field => "userPassword",
password_type => "crypted",
},
store => {
class => "LDAP",
binddn =>
"cn=proxyagent,ou=profile,dc=xyz,dc=company,dc=com",
bindpw => "proxy",
ldap_server => "my.host.name",
ldap_server_options => { timeout => 30 },
start_tls => 0,
use_roles => 0,
user_basedn => "ou=People,dc=company,dc=com",
user_field => "uid",
user_filter => "(&(objectClass=posixAccount)(uid=
%s))",
user_scope => "one",
user_search_options => { attrs => ['*'] },
},
},
},
},
);
Reusing some of the code from "The Book" I have implemented a login
action:
sub login : Global Form {
my ($self, $c) = @_;
my $form = $self->formbuilder;
return unless $form->submitted && $form->validate;
if ($c->authenticate({username => $form->field('username'),
password => $form->field('password')})){
$c->flash->{message} = "Logged in successfully.";
$c->res->redirect($c->uri_for('/'));
$c->detach;
}
else {
$c->stash->{error} = "Login failed.";
}
}
I have tested the C::A::Store::LDAP ability to talk to the server by
first using a bogus hostname (which generated an error) and putting
a bogus password in for my proxy account (which generated an error)
so I know that the issue is with the final phase of testing the
user's password hash. >From the debug output of the server I see
this happen when trying to authenticate:
[CGI::FormBuilder::Field::validate] (debug1) password: validation
passed
[CGI::FormBuilder::validate] (debug1) validation done, ok = 1
(should be 1)
[CGI::FormBuilder::field] (debug2) called $form->field(username)
[CGI::FormBuilder::field] (debug2) searching fields for 'username'
[CGI::FormBuilder::Field::value] (debug2) username: called $field-
>value()
[CGI::FormBuilder::Field::value] (debug2) username: sticky && ! force
[CGI::FormBuilder::Field::cgi_value] (debug2) username: called
$field->cgi_value
[CGI::FormBuilder::Field::cgi_value] (debug2) username: cgi value =
(uname)
[CGI::FormBuilder::Field::value] (debug1) username: returning value
(uname)
[CGI::FormBuilder::Field::inflate_value] (debug2) username: called
$field->inflate_value
[CGI::FormBuilder::field] (debug2) called $form->field(password)
[CGI::FormBuilder::field] (debug2) searching fields for 'password'
[CGI::FormBuilder::Field::value] (debug2) password: called $field-
>value()
[CGI::FormBuilder::Field::value] (debug2) password: sticky && ! force
[CGI::FormBuilder::Field::cgi_value] (debug2) password: called
$field->cgi_value
[CGI::FormBuilder::Field::cgi_value] (debug2) password: cgi value =
(sdfd)
[CGI::FormBuilder::Field::value] (debug1) password: returning value
(sdfd)
[CGI::FormBuilder::Field::inflate_value] (debug2) password: called
$field->inflate_value
Use of uninitialized value in crypt at /usr/lib/perl5/site_perl/
5.8.8/Catalyst/Authentication/Credential/Password.pm line 69.
Use of uninitialized value in crypt at /usr/lib/perl5/site_perl/
5.8.8/Catalyst/Authentication/Credential/Password.pm line 69.
Use of uninitialized value in string eq at /usr/lib/perl5/
Re: [Catalyst] Distributed session storage problems/questions
Hello Matt, This looks like a version mismatch of the Catalyst::Authentication::Store::DBIx::Class module on the two machines. Recently I added functionality to the module which allow users to avoid the DB hit when restoring a user from the session, part of this change entailed changing the data stored in the session for a user. The old module simply stored the user's ID in the session. The new way stores all the user information in the session, and then attempts to restore it either using the id field or, if caching is turned on, all the fields stored. It sounds like one of your machines is using the older version of the module and one is using the newer version of the module. Bring the modules into sync and the problem should go away. Though I expect that at least half of your sessions will need to be reset because you probably have 2 different types of data in there now from authentication on the two machines. Jay On Feb 20, 2008, at 11:08 AM, Matt Pitts wrote: We have a load balanced application where the proxy does *not* force any type of sticky session with each backend. The app was running in production as a single instance (pre load-balanced) and we moved it behind the proxy to be able to add backends and make it load balanced. I had the app in test for several weeks as a load-balanced setup using memcached to store sessions across the 2 backends and I am pretty confident that the auth areas that relied on session storage were working fine. As of last night the app throws errors (in UAT) about every other request when inside an auth area with the 2 backends enabled. I can’t get the actual message as this time, but it basically was a “Can’t use 12345 as a HASHREF…” type of error where ‘12345’ is the ID of the user I was authenticated as. If I disable one of the backends, clear my cookies and re-login the entire session works fine. As soon as I re-enable the other backend I start getting the errors again and it doesn’t matter which backend I use first, they both work independent of one another. Obviously, the first backend that stores the session works and the other doesn’t, but what I don’t know is why. As I stated above, I’m pretty confident that all the auth areas of the site were functioning in the load-balanced setup before we went to PROD. So, I looked at what changed and the only thing that changed related to session storage was that I added a 2nd memcached backend instance to the config file. I wondered if this might have been part of the problem, but I have since dropped back to only one memcached instance, restarted it and the errors still persist. Here is the relevant config section: session: flash_to_stash: 1 expires: 3600 memcached_new_args: data: - 10.xxx.xxx.xxx:11211 namespace: tangeroutlet_tangerweb_session_uat In an effort to troubleshoot this I have also tried to implement memcached storage using C::P::Session::Store::Cache and C::P::Cache::Memcached, but I haven’t gotten this to work yet. I’m hoping that answers to the following questions will guide me to a solution: 1. What is the acceptable way to use memcached for session storage? Is it using C::P::Session::Store::Memcached or is it C::P::Session::Store::Cache in conjunction with C::P::Cache::Memcached? 2. Is memcached even a “good” way to store sessions? DBIC seems to be a popular option, but I figured memcached’s considerable speed would make it the preferred choice. 3. When using memcached to store sessions, is it OK to have more than one backend? At first I didn’t think anything about adding another backend, but then I thought that the 2 memcached instances wouldn’t have the same set of data which would cause problems with sessions, unless of course the session writes get distributed to all the backends. I’ve looked into the source of C::P::Session::Store::Memcached, Cache::Memcached::Managed and Cache::Memcached and cannot tell if the writes are spread across all backends. Does anyone know the answer to this? 4. Is it just crazy to run a load balanced setup without some type of sticky session setup on the proxy? If so, any implementations of this using Apache 2.x mod_proxy(_balancer) as the frontend would be greatly appreciated. At this point I think I’d be willing to take a performance hit and store sessions in DBIC if it’s going to work better in a distributed environment. TIA for any input. 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/ --- "May we not return to those scoundrels of old, the illustrious founders of superstition and fanaticism, who first took the knife from the altar to make victims of those who refused
Re: [Catalyst] $c->user->some_relationship always retrives user id from the db
Hi There,
I suppose now is as good a time as any - The
Catalyst::Authentication::Store::DBIx::Class module currently on CPAN
has the 'avoid the db hit' code is in it. It is not enabled by
default, but add 'use_userdata_from_session => 1' to your config and
it will not reload from the database unless you specifically request
it. See the docs:
http://xrl.us/bgbn9
(aka
http://search.cpan.org/~jayk/Catalyst-Authentication-Store-DBIx-Class-0.104/lib/Catalyst/Authentication/Store/DBIx/Class.pm#CONFIGURATION
)
as there are some things you should know about operating in that mode.
Jay
On Feb 16, 2008, at 8:20 AM, Moritz Onken wrote:
If someone tells me where to put that kind of code Matt suggested
I'll write a patch and some (1? :-) ) tests.
Am 15.02.2008 um 02:16 schrieb Guillermo Roditi:
Which means the entire thing would be pointless. What you want to do
really is
$class->new({ %saved_stuff, -result_source => $schema-
>source($class) });
$new_obj->in_storage(1);
then it'll work "as if" you re-fetched the object (%saved_stuff
being the
return of $obj->get_columns). Making stuff work with only the PK
stashed
in the session is left as an exercise to the reader, but would
probably
be best done using Data::Thunk and Data::Swap.
/me confoos. Why not just use the shiny new freeze / thaw hooks?
Wouldn't it make sense to store a frozen version of the User row /
object in the session and then thaw it upon request? This seems like
it would be a really natural way to cache this information. Ideally,
the thawing would be a lazy operation as well i think.
I just bring this up because the code you just sent would not work
when one is using things like DigestColumns or EncodedColumn, which
are most commonly seen in User-type objects
--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/
___
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/
---
"May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples."
- 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] $c->user->some_relationship always retrives user id from the db
Thanks for the suggestion, I will probably go that route. It's
somewhat simpler than my previous plan.
Jay
On Feb 14, 2008, at 1:19 PM, Matt S Trout wrote:
On Thu, Feb 14, 2008 at 11:06:09AM -0700, Jay K wrote:
So why do I need to recovery the whole user row for every request?
I could use
$user_id = $c->session->{user_id};
@albums = $c->model('albums')->search({ user_id => $user_id });
as Mitchell suggested but I'd prefer to fetch the data by using $c-
user because its the way one should do it.
might it be possible to store the user row in the session at login
and recover $c->user from the session on every request?
I know this might break if I change something in the user row.
Hi again Moritz,
Matt is correct - Because nobody has written the 'store everything in
the session' bit yet. I have a plan to change the DBIx::Class store
so that it will save the row info into the session - but I have not
done so yet. The next release will include that functionality, but
at this time I can't tell you when exactly that will be. I'm going
to
try to get it done this weekend.
In anticipation of that - I can tell you that you should use $c-
>user-
get('fieldname'); When my code is complete, that will be the 'don't
hit the database' way of accessing row information. Accessing $c-
user->obj or $c->user->get_object will trigger the DB hit. And
since $c->user->fieldname just relays to $c->user->get_object-
fieldname - the shortcut method won't work either if you want to
avoid the db hit.
But then you can't follow even PK relationships without the db hit.
Which means the entire thing would be pointless. What you want to do
really is
$class->new({ %saved_stuff, -result_source => $schema-
>source($class) });
$new_obj->in_storage(1);
then it'll work "as if" you re-fetched the object (%saved_stuff
being the
return of $obj->get_columns). Making stuff work with only the PK
stashed
in the session is left as an exercise to the reader, but would
probably
be best done using Data::Thunk and Data::Swap.
--
Matt S Trout Need help with your Catalyst or DBIx::Class
project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment
platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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] $c->user->some_relationship always retrives user id from the db
So why do I need to recovery the whole user row for every request?
I could use
$user_id = $c->session->{user_id};
@albums = $c->model('albums')->search({ user_id => $user_id });
as Mitchell suggested but I'd prefer to fetch the data by using $c-
>user because its the way one should do it.
might it be possible to store the user row in the session at login
and recover $c->user from the session on every request?
I know this might break if I change something in the user row.
Hi again Moritz,
Matt is correct - Because nobody has written the 'store everything in
the session' bit yet. I have a plan to change the DBIx::Class store
so that it will save the row info into the session - but I have not
done so yet. The next release will include that functionality, but
at this time I can't tell you when exactly that will be. I'm going to
try to get it done this weekend.
In anticipation of that - I can tell you that you should use $c->user-
>get('fieldname'); When my code is complete, that will be the 'don't
hit the database' way of accessing row information. Accessing $c-
>user->obj or $c->user->get_object will trigger the DB hit. And
since $c->user->fieldname just relays to $c->user->get_object-
>fieldname - the shortcut method won't work either if you want to
avoid the db hit.
Jay
---
"May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples."
- 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] $c->user->some_relationship always retrives user id from the db
Hi there Moritz,
The select by id that you are seeing is the retrieval of the user from
the database when first recovering the user from the session. I am
assuming that you are using the
Catalyst::Authentication::Store::DBIx::Class storage module. Any
access to $c->user will trigger this query. It is, however, only done
once per request.
In short - if you are going to be using $c->user in any way during the
request, that find by id will be done at some point. So going out of
your way to avoid it only makes sense if you are sure you will not use
any other user information during the request.
Jay
On Feb 13, 2008, at 1:33 PM, Mitchell Jackson wrote:
You don't have to do queries using relationship behavior if you
don't like the way it works. For example:
$user_id = $c->session->{user_id};
@albums = $c->model('albums')->search({ user_id => $user_id });
Mitch
Moritz Onken wrote:
Hi,
I request all albums of a user by calling $c->user->albums->all;
That results in a query which retrieves the user id and then querys
the album table with that user id in the where clause.
It works, but how can I prevent that first query which retrieves
the user id? Can't I store the user id in the session so that the
query could use that value instead of receiving it from the database?
I looked through the docs but couldn't find anythink. I hope this
is the right place to ask.
Thanks in advance,
moritz
___
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/
---
"May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples."
- 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] installing Catalyst::Plugin::Authentication::Store::LDAP
Let's try that again: It's also a simple and clear way to move modules to the new auth scheme without having to maintain backwards compatibility. The new naming also makes it clear that the module is meant for use with the current system, as the old system required the modules to be plugins. Jay It's also a simple and clear way to move modules to the new auth scheme without having to maintain backwards compatibility. with the old credential is meant for use with the current auth system. Jay --- "May we not return to those scoundrels of old, the illustrious founders of superstition and fanaticism, who first took the knife from the altar to make victims of those who refused to be their disciples." - 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/ --- "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] installing Catalyst::Plugin::Authentication::Store::LDAP
Catalyst::Authentication::Store::XYZ Catalyst::Authentication::Credential::XYZ What's the recommended approach for existing stores and credentials? Rename them and mark the old ones as deprecated? Create new stubs with the new names that just subclass the existing plugins? Well - Overall to update to the new naming scheme and then deprecate the old ones, yes. It's also a simple and clear way to move modules to the new auth scheme without having to maintain backwards compatibility with the old credential is meant for use with the current auth system. Jay --- "May we not return to those scoundrels of old, the illustrious founders of superstition and fanaticism, who first took the knife from the altar to make victims of those who refused to be their disciples." - 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] installing Catalyst::Plugin::Authentication::Store::LDAP
Catalyst::Authentication::Store::XYZ Catalyst::Authentication::Credential::XYZ What's the recommended approach for existing stores and credentials? Rename them and mark the old ones as deprecated? Create new stubs with the new names that just subclass the existing plugins? Well - Overall to update to the new naming scheme and then deprecate the old ones, yes. It's also a simple and clear way to move modules to the new auth scheme without having to maintain backwards compatibility with the old credential is meant for use with the current auth system. Jay --- "May we not return to those scoundrels of old, the illustrious founders of superstition and fanaticism, who first took the knife from the altar to make victims of those who refused to be their disciples." - 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] installing Catalyst::Plugin::Authentication::Store::LDAP
Hi all, I can shed some light here. As of Catalyst::Plugin::Authentication version 0.10003 - the default naming for stores and credentials is Catalyst::Authentication::Store::XYZ and Catalyst::Authentication::Credential::XYZ The Store and Credential modules that have been updated to work with realms are not loaded as Catalyst Plugins, and the fact that the namespace indicated plugin was confusing people. As of 0.10003 - the default action is to look for modules using the correct namespace, and if not found, fall back to the old namespace. That is all the debug message is saying, that it fell back to the old-style of naming. It's not an error and will not break anything. The debug message is there in case you are intending to load a Catalyst::Authentication::XYZ module and your app is not finding it... which could cause problems if an older module is being found and loaded instead. If the debug message really bothers you, you can specify the full module name (prefixed with +) instead of just 'Password' or 'Store::LDAP'. Hope that clears things up, Jay On Jan 24, 2008, at 1:49 PM, Andrew Peebles wrote: rahed wrote: On 1/24/08, Peter Karman <[EMAIL PROTECTED]> wrote: you did not miss anything. There are tests for this timeout issue in svn already but I am waiting on some other issues before making a new release of ::Store::LDAP. The tests try and access openldap.org and timeout if they can't reach it. So you can safely ignore those test failures for now. Thank you, I will gladly be ignorant. What's this about? [warn] Store class "Catalyst::Authentication::Store::LDAP" not found, trying deprecated ::Plugin:: style naming. This is a clean install of Cat (yesterday) ... perl -MCPAN -e 'install Catalyst::Authentication::Store::LDAP' CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Wed, 23 Jan 2008 23:30:57 GMT Warning: Cannot install Catalyst::Authentication::Store::LDAP, don't know what it is. Try the command ?? ___ 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] Re: "Rails is a Ghetto"
Yeah. I gotta say, while I agree with many of Zed's points about rails and it's community... his method of delivery just makes me think that however smart he might be, he's somewhat immature. Before I found Catalyst a couple years back, I was looking for a new system to work with. Rails was at the top of the heap and generating much buzz at the time, so I attempted it for a while, and I came to many of the same conclusions he did. After a couple of months I abandoned it and went looking for a more mature / workable system and a less fanboy / more mature community. I found that in Catalyst. It is a shame that it took him so long to reach the same conclusions. I'm sad to see that he went through some tough times because of it, but the level of venom just makes him look immature. Rails was a bad choice, yes, for many of the reasons he describes, yes. But take some responsibility for your decisions and make some better choices. I'm glad that Catalyst has the community it has, and I don't welcome the thought of Rails deserters joining Catalyst ranks with Fanboy enthusiasm and a penchant for loosing venom towards those they can't convince of their rightness. :-/ Jay On Jan 5, 2008, at 12:17 PM, Daniel McBrearty wrote: wow! that's some rant. couldn't read it all the way, but half was enough ... ___ 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/ --- "May we not return to those scoundrels of old, the illustrious founders of superstition and fanaticism, who first took the knife from the altar to make victims of those who refused to be their disciples." - 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] Legacy porting to auto-authenticate a logged in user
Hi Ashley,
My guess is that your password hashing type in the db is different
from the password hashing type you defined for the Password credential.
Since your database does store the password in plaintext - why not set
password type to 'clear' - and set the password_field to password.
This should cause authentication to happen against your unencrypted
password and should work.
Jay
On Dec 23, 2007, at 10:10 AM, Ashley Pond V wrote:
Thanks for the idea. Didn't work. After following the code trail
back through a few namespaces and lots of config v class_data v
eyes glaze over, I fixed it by setting the password_type to "none"
and merely authenticating on the "username."
This is fine in this case but it's obviously less than ideal. If
anyone has insight into what I'm doing wrong with my original
version, I'd love to hear it.
WORKING VERSION (username isn't guaranteed unique so I went with the
Id instead):
$c->authenticate({ acctid => $user->acctid })
or die "RC_403: " . $user->username . ": " . $user->acctid . "
failed to authenticate";
authentication:
default_realm: users
realms:
users:
credential:
class: Password
password_type: none
#password_hash_type: SHA-1
#password_field: crypt_passwd
store:
class: DBIx::Class
user_class: DB::User
id_field: acctid
On Dec 22, 2007, at 3:44 AM, Peter Edwards wrote:
Try
$c->authenticate({ acctid => $user->username,
password => $user->password })
or die "RC_403: " . $user->username . " failed to
authenticate";
Regards, Peter
-Original Message-
From: Ashley Pond V [mailto:[EMAIL PROTECTED]
Sent: 22 December 2007 08:08
To: The elegant MVC web framework
Subject: [Catalyst] Legacy porting to auto-authenticate a logged in
user
I have what I first thought was a gimme (this is only tangentially
related to the questions I asked a few days ago; same app, different
DB and part). Legacy porting of a "login" with Authenticate where I
already have the user id and everything verified. I have tried many
permutations of arguments and setup.
The user has already logged into the legacy part of the app. So this
is the code that is not working but I think should.
my $user_id = ...legacy fetch; working fine
my $user = $c->model("DB::User")->find($user_id)
or die "RC_403: No such user for id $user_id"; # also working
fine
# this dies, I've verified the $user, username, and password are
correct
$c->authenticate({ username => $user->username,
password => $user->password })
or die "RC_403: " . $user->username . " failed to
authenticate";
So. why? The legacy setup is a little strange so I think that must be
it. The user table's DBIC looks like this (password is plaintext,
legacy, and crypt_passwd is sha1 of it)-
package MyApp::DB::User;
use base qw/DBIx::Class/;
__PACKAGE__->load_components(qw/PK::Auto Core/);
__PACKAGE__->table('foo.account');
__PACKAGE__->add_columns(qw/ acctid email fname lname password
crypt_passwd /);
__PACKAGE__->set_primary_key('acctid');
sub username {
+shift->email;
};
My config looks like this-
authentication:
default_realm: users
realms:
users:
credential:
class: Password
password_field: crypt_passwd
password_type: hashed
password_hash_type: SHA-1
store:
class: DBIx::Class
user_class: DB::User
id_field: acctid
Thanks for looking!
-Ashley
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
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/[EMAIL PROTECTED]/
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/[EMAIL PROTECTED]/
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Can't locate Catalyst/Plugin/Authentication/Store/DBIC.pm
Hi Michael,
Unfortunately the Tutorial is a bit out of date.
Please look at this:
http://search.cpan.org/~jayk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication.pm
and this:
http://search.cpan.org/~jayk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm
and your issues should be cleared up.
Jay
On Dec 17, 2007, at 7:07 PM, Michael Higgins wrote:
PANIC!!!
So, the gentoo overlay installation is altered like:
dev-perl/Catalyst-Authentication-Store-DBIx-Class
!dev-perl/Catalyst-Plugin-Authentication-Store-DBIx-Class
!dev-perl/Catalyst-Plugin-Authentication-Store-DBIC
Okay... no more 'Plugin' or 'DBIC' anymore, it seems.
Then I did find this:
http://cpan.uwinnipeg.ca/htdocs/Catalyst-Authentication-Store-DBIx-Class/Catalyst/Authentication/Store/DBIx/Class.html
And, I try to change a couple of items in the configs, like so:
authentication => {
default_realm => 'members',
realms => {
members => {
credential => {
class => 'Password',
password_field => 'password',
password_type => 'clear'
},
store => {
class => 'DBIx::Class',
user_class => 'MyAppDB::Users',
id_field => 'user_id',
role_relation => 'userroles',
role_field => 'role_name',
}
... to mimic what is in that doco.
Caught exception in BanTrace::Controller::Login->index "The user
object
Catalyst::Authentication::Store::DBIx::Class::User=HASH(0x9469e70)
does
not support any known password authentication mechanism.,,
...here:
35: if ($username && $password) {
36:
37: # Attempt to log the user in
38: if ($c->login($username, $password)) {
WTF
My application is configured exactly like the tutorial... used to be
written?? No. It still looks like: Authentication::Store::DBIC
And that Plugin:: isn't part of the installation now... this _can't_
be
okay, no?
Alright, so this is the new 'login' method, 'authenticate'?
37: # Attempt to log the user in
38: # if ($c->login($username, $password)) {
39: if ($c->authenticate($username, $password)) {
Caught exception in BanTrace::Controller::Login->index "authenticate
called with nonexistant realm: 'MYPASSWORD'?
Ouch! Oh, with a hashref, now:
# if ($c->login($username, $password)) {
if ($c->authenticate({username => $username, password =>
$password}))
So now I'm in... sort of. Other parts are broken...
if ($c->check_user_roles('admin')) {
... didn't seem to fly.
Now, I'm stuck. That method comes from, I think, ::DBIC ... what's the
new way? Fortunately, in this app, if you are not 'admin' you must
be a
user... but I'd like to have my ROLE back!!!
Any help really, really appreciated. '-)
Cheers,
--
|\ /|| | ~ ~
| \/ ||---| `|` ?
||ichael | |iggins\^ /
michael.higgins[at]evolone[dot]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/[EMAIL PROTECTED]/
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] "no role configuration found" -- authorization: dbic and DBI::Schema::Loader
Hi Ashley,
The log message you see is a result of the recent move away from the
Catalyst::Plugin::Authentication namespace for stores / credentials.
It falls back to the old naming and warns if it can't find the new
module.. It should, however, have no effect on the functionality of
the code.
It's not a bad idea to update the DBIx::Class store - but be sure to
remove the Catalyst::Plugin::Authentication::Store::DBIx::Class module
first - just to avoid conflicts. Nothing has changed related to roles
in the update, so it shouldn't make any difference.
I don't know why the assert is failing, it should not - what do you
get if you use $c->check_user_roles() - valid results?
Jay
On Dec 16, 2007, at 4:27 PM, Ashley Pond V wrote:
Continuing saga. So I set up the many_to_many and lo! It worked. But
it worked with *any* role, even fake ones, so obviously something
was bad. Turned out that it was silently failing instead of throwing
an access exception (but there was a template set by the namespace
so the page rendered as expected).
# failed silently (as far as Cat was concerned)
$c->assert_user_roles("there is no role called this");
So, dug into the log:
[Sun Dec 16 16:13:20 2007] [error] [client 67.170.68.172] [warn]
Store class "Catalyst::Authentication::Store::DBIx::Class" not
found, trying deprecated ::Plugin:: style naming. , referer: [...]
Would love to have more, rather than fewer exceptions thrown. I
think the missing class was the cause of a couple of red herrings I
followed down the rabbit hole trying to get this running yesterday
[I'm entitled to mix metaphors, I pay an annual fee]. After I get an
admin to install the missing package in the morning I'll regale you
with my next series of missteps and annoying language.
Live free or die early, die often,
-Ashley
On Dec 15, 2007, at 9:52 PM, Jay K wrote:
Hi There Ashley,
The DBIx::Class module expects to use the relation provided in the
role_relation config element to retrieve one or more rows, which
must contain a field called by whatever you provide in role_field.
My guess is that your user_roles table is a cross-ref table -
userid and roleid essentially. In order to solve this you need to
use a many_to_many relationship mapping to the textual role names.
The DBIx::Class module expects you are going to route it to the
information it needs using the role_relation. So what you really
need to do is create the schema class and just define the many-to-
many for roles. Then provide that relation to 'role_relation' and
all your problems should go away.
It still works with dynamic schema - but you have to create the
relationship. You can do that by creating your schema module to
look something like this:
package MyApp::Schema::Users;
use strict;
use warnings;
use base 'DBIx::Class';
__PACKAGE__->load_components("PK::Auto", "Core");
__PACKAGE__->has_many('roles_map', "MyApp::Schema::RoleMap",
user_id');
__PACKAGE__->many_to_many( roles => 'role_map, 'role');
1;
I might have that slightly wrong - I've been moving today so I'm a
bit overtired. but basically that allows your schema to
dynamically figure itself out, but you define the relationships for
it.
For some database types, DBIx::Class can figure out your
relationships for you - but I don't think it can sort out many-to-
many's anyway.
Hope that helps. And I hope it makes as much sense to you as I
make to myself in my head at the moment. This, I understand, may
not be the case. If not, I'll try again tomorrow.
Jay
On Dec 15, 2007, at 5:57 PM, Ashley Pond V wrote:
Progressing… Looking at Catalyst/Plugin/Authentication/Store/DBIC/
User.pm I saw a couple of items in the "authentication" config I
could set. With "role_relation" and "role_field" set--
authentication:
default_realm: users
realms:
users:
credential:
class: Password
password_field: password
password_type: hashed
password_hash_type: SHA-1
store:
class: DBIx::Class
user_class: User
role_relation: user_roles
role_field: role
--I now get the roles checked but they are failing because they
are checking (returning) the role "id" instead of the "name."
$c->user->roles returns a list of the IDs too. So, from reading
this,
Catalyst::Plugin::Authentication::Store::DBIx::Class::roles()
it looks like dynamic loader schemas are incompatible right now?
I'm trying to figure this out but there is a lot of inter-related
code to read, cross-package-configuration, and documentation drift/
lag.
Throw me a bone, er, a line!
-Ashley
On Dec 15, 2007, at 10:18 AM, Ashley Pond V wrote:
Can you elaborate? "map_user_role"
Re: [Catalyst] "no role configuration found" -- authorization: dbic and DBI::Schema::Loader
Hi There Ashley,
The DBIx::Class module expects to use the relation provided in the
role_relation config element to retrieve one or more rows, which must
contain a field called by whatever you provide in role_field.
My guess is that your user_roles table is a cross-ref table - userid
and roleid essentially. In order to solve this you need to use a
many_to_many relationship mapping to the textual role names.
The DBIx::Class module expects you are going to route it to the
information it needs using the role_relation. So what you really need
to do is create the schema class and just define the many-to-many for
roles. Then provide that relation to 'role_relation' and all your
problems should go away.
It still works with dynamic schema - but you have to create the
relationship. You can do that by creating your schema module to look
something like this:
package MyApp::Schema::Users;
use strict;
use warnings;
use base 'DBIx::Class';
__PACKAGE__->load_components("PK::Auto", "Core");
__PACKAGE__->has_many('roles_map', "MyApp::Schema::RoleMap", user_id');
__PACKAGE__->many_to_many( roles => 'role_map, 'role');
1;
I might have that slightly wrong - I've been moving today so I'm a bit
overtired. but basically that allows your schema to dynamically
figure itself out, but you define the relationships for it.
For some database types, DBIx::Class can figure out your relationships
for you - but I don't think it can sort out many-to-many's anyway.
Hope that helps. And I hope it makes as much sense to you as I make
to myself in my head at the moment. This, I understand, may not be
the case. If not, I'll try again tomorrow.
Jay
On Dec 15, 2007, at 5:57 PM, Ashley Pond V wrote:
Progressing… Looking at Catalyst/Plugin/Authentication/Store/DBIC/
User.pm I saw a couple of items in the "authentication" config I
could set. With "role_relation" and "role_field" set--
authentication:
default_realm: users
realms:
users:
credential:
class: Password
password_field: password
password_type: hashed
password_hash_type: SHA-1
store:
class: DBIx::Class
user_class: User
role_relation: user_roles
role_field: role
--I now get the roles checked but they are failing because they are
checking (returning) the role "id" instead of the "name."
$c->user->roles returns a list of the IDs too. So, from reading this,
Catalyst::Plugin::Authentication::Store::DBIx::Class::roles()
it looks like dynamic loader schemas are incompatible right now? I'm
trying to figure this out but there is a lot of inter-related code
to read, cross-package-configuration, and documentation drift/lag.
Throw me a bone, er, a line!
-Ashley
On Dec 15, 2007, at 10:18 AM, Ashley Pond V wrote:
Can you elaborate? "map_user_role" ne "user_role." I have
"role_rel" set to the UserRole class. I tried adding "user_role"
but it didn't help and I don't see it anywhere in the docs.
I should rephrase, I think. Is anyone using DBIC::Schema::Loader
dynamically with role authorization? If so, please share your
configuration or advise of which FMTR.
Thanks again,
-Ashley
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] backward compatibility problem with new C::P::Authentication (for info only)
Hi There, Yes. get_user is a compatibility call and only really works properly when in compatibility mode - IE along with $c->login and placing all the modules in the use Catalyst section. The chances are the reason it doesn't work is that it is the old call based on whatever the argument is being the 'id' in the record. This doesn't make a whole lot of sense in the new configuration. $c->user or $c->user->obj is the correct way to get the currently authenticated user (this has not changed from the old api) Jay On Dec 13, 2007, at 2:53 PM, Daniel McBrearty wrote: everything seems to be running fine now after a few code updates. I came across one oddity though that might be of interest. In my old code, I had this construct in a few places, to get the user object from the database: my $user = $c->get_user( $username ); It seems that the get_user method was working, but somehow returning entirely the wrong user object from the database. This was probably a really crappy way of doing things, and using $c->user instead fixes everything. Even so, it looks like buggy behaviour - maybe get_user needs to be removed or be fixed or something (I couldn't even find docs for it in new code, so I am not sure which module is actually implementing it 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/[EMAIL PROTECTED]/ 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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
