[Catalyst] Catalyzed.org - Interview with Tomas Doran on the Catalyst 5.8 Release

Hello everyone, For those who are interested, I wanted to pass along that there is an interview with Tomas Doran regarding the Catalyst 5.8 release up on http://www.catalyzed.org/ It's worth a read if you are interested in the what and why of the 5.8 release. Thanks! Jay

[Catalyst] [Announce] Catalyzed.org launched

Hi All, I just wanted to take a moment to announce that Catalyzed.org ( http://www.catalyzed.org ) officially launched today. Catalyzed.org is a site dedicated to Modern Perl and Catalyst development. We created it to cover all the exciting things that are going on in the world of Perl, and

[Catalyst] ANNOUNCE: Progressive authentication attempts

Hello All, A new version of the Catalyst Authentication plugin is winging it's way to CPAN (0.100091.) This update includes the excellent 'Catalyst::Authentication::Realm::Progressive' realm written by J. Shirley. The Progressive Realm allows you to, with a single call to $c- authenticate(),

Re: [Catalyst] Numerous Authorization queries

Yes, this is the intended behaviour. The data isn't cached in any way. What I've done to circumvent that is to load all of the roles as a hashref in $c-stash-{ user_roles } in my auto sub, and just consult that stash data whenever i need to check roles. Brian, is this really true? Using the

Re: [Catalyst] Simple caching question

Given how light my requirements are--the app's been chugging along fine for years without any caching--I don't think I need to bother putting another app into the mix. The memory requirements for Memcached don't worry me--the server never goes down, and even if it did, another round of database

Re: [Catalyst] ANNOUNCE: SimpleDB - Auth configuration made easy

I think a good approach is to have safer more secure defaults, and if users explicitly turn those off then have relevant warnings on by default, and if users really know what they're doing then they can explicitly turn those off. For example, users can have an explicit

Re: [Catalyst] ANNOUNCE: SimpleDB - Auth configuration made easy

I made the default 'clear', as the tutorial uses 'clear' and it is the least likely to cause failure of auth for those just coming to catalyst / going through the tutorials. The password_type config option allows changing it to something more reasonable for production use. Matt and I discussed

Re: [Catalyst] ANNOUNCE: SimpleDB - Auth configuration made easy

If I explicitly override the default, by explicitly requesting 'clear', because my requirements explicitly need this ability, then I must change the code to get rid of the warning? Ahh, but it's for the 'simple', who must be guided, and can't be bothered to read the warnings in the text so

[Catalyst] ANNOUNCE: SimpleDB - Auth configuration made easy

Hey all, Catalyst authentication configuration just got a whole lot easier. I just released two updates to CPAN that will make Auth configuration much much easier for the 'average' case where you have user data stored in an SQL database and you are using passwords for authentication. Now, the

[Catalyst] Simplified auth configuration - input requested

Hi All, Some folks have mentioned recently that the Catalyst::Plugin::Authentication system while being quite flexible is somewhat difficult to understand / set up initially. I am soliciting comments regarding the issues that people have had and what changes people would like to see. Better

Re: [Catalyst] Simplified auth configuration - input requested

Also - before I forget - I am interested in hearing about any errors / configs that were broken, but produced confusing and/or unhelpful messaging about why they were broken. Jay On Oct 20, 2008, at 11:55 AM, Jason Kuri wrote: Hi All, Some folks have mentioned recently that the Catalyst

Re: [Catalyst] [PATCH] [RFC] Override base URI

Great work. I was looking into this yesterday. I'm glad you beat me to it. :-) To follow up on Tomas' comment - Why not make the override_base_uri / override_base_uri_secure include the schema? So if you want the URI's to include https:// even if the request is coming in not-secure, you can

Re: [Catalyst] minor typo in Catalyst::Authentication::Store::DBIx::Class::User

Hi John, Thanks for catching that. I've incorporated the fix and pushed a new version. It should be on CPAN soon. Thanks again, Jay On Sep 28, 2008, at 9:08 AM, John Romkey wrote: On Sep 28, 2008, at 9:43 AM, Matt S Trout wrote: On Fri, Sep 26, 2008 at 11:17:05AM -0400, John Romkey

Re: [Catalyst] Patch for Catalyst::Authentication::Store::DBIx::Class::User

On Thursday 21 August 2008 23:12:40 David Jack Wange Olrik wrote: Wouldn't it be neat to have the username field configurable, just like 'password_field' ? You don't need that, read this: [ ... ] Basically you pass whatever hashref you need to $c-authenticate. The password_field is necessary

Re: [Catalyst] Patch for Catalyst::Authentication::Store::DBIx::Class::User

Hi David, Thanks for the patch, but I think you are misunderstanding the use of id_field. The id_field config option is only used when saving to / restoring from the session, it has no relation to what you pass to the $c- authenticate() call. By default,

Re: [Catalyst] Issue with Catalyst::Plugin::Authentication and updating user information (jayk, looking at you!)

Follow up for the list. This turned out to be caused by a config problem. id_field was set to the username field... which meant that the session was attempting to restore using the old username as the key. Setting the id_field to username is fine unless you change the username during the