Re: [Catalyst] "Catalyst::Plugin::Authentication uses NEXT, which is deprecated."
Hi Paul,
It's actually pretty easy. Define a many_to_many relationship in your user to
your role data.
Then use that instead of your 'has_many' in your Auth config.
That's really it.
Jay
On May 11, 2010, at 2:11 PM, Paul Makepeace wrote:
> On Sun, May 9, 2010 at 18:25, Paul Makepeace wrote:
> [snip to the most puzzling stuff]
>> Finally, we have our roles via a join: user <-- user_role --> role. It
>> seems like role_field is expecting a string but it's here getting an
>> integer. Is there anyway of having go further into the role table with
>> that integer key and compare on role.role?
>>
>> We used to use,
>> __PACKAGE__->config->{authorization}->{dbic} = {
>> role_class => 'DBIC_Readonly::Role',
>> role_field => 'role',
>> role_rel => 'map_user_role',# DBIx::Class only
>> user_role_user_field => 'user',
>> };
>>
>> Now,
>> __PACKAGE__->config->{authentication} = {
>> default_realm => 'members',
>> realms => {
>>members => {
>> credential => {
>>class => 'Password',
>>password_field => 'password',
>>password_type => 'clear',
>> },
>> store => {
>>class => 'DBIx::Class',
>>user_model => 'DBIC_Readonly::User',
>>role_relation => 'map_user_role',
>>role_field => 'role',
>> },
>>},
>> },
>> };
>>
>> with, (unchanged),
>> User.pm,
>> __PACKAGE__->has_many(map_user_role => 'IDL::Schema::UserRole' => 'user');
>
> Anyone have an idea here? Any more info I can provide? I'm assuming
> this isn't a functional regression but I'm at a loss what to do here.
> I could change user_role to have strings instead of an FK to role but
> would rather not as we lose some protection against bad role
> names/data integrity.
>
> Paul
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Building complex layouts
We created Subinclude for exactly this purpose: http://search.cpan.org/dist/Catalyst-View-Component-SubInclude/lib/Catalyst/View/Component/SubInclude.pm Include another bit of output from a Catalyst app via a number of methods, including ESI and SubRequests. Makes including those pieces particularly easy too, as it doesn't require you to know in your action what you'll need in your view. Jay On Dec 30, 2009, at 7:15 AM, Lars Balker Rasmussen wrote: > On Wed, Dec 30, 2009 at 2:49 PM, Peter Corlett wrote: >> On 30 Dec 2009, at 10:11, Lars Balker Rasmussen wrote: >> [...] >>> >>> Definitely split sidebars etc. into separate actions. Then have nginx, >>> varnish or equiv. combine them with SSI/ESI. This also helps caching across >>> pages. >> >> Does Catalyst's built-in web server support either technology yet? If not, >> you're going to find it harder to debug your site if you use them. > > Meh, it'd be a trivial plugin to write, if nobody hasn't already. > -- > Lars Balker RasmussenConsult::Perl > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] anyone used Varnish yet?
Hi! I've used varnish a lot. (I also wrote the advent article) and the followup: http://www.catalystframework.org/calendar/2008/17 It is very nice, much better than the alternatives (squid, etc.) It takes a little getting used to, but it gives you incredible control over how you handle requests. One thing I will say is always specify your storage methods. By default it will grab like half of the available memory (or something like that) and it's rare that you need that. Also be wary of the cookie handling. You need to add cache control to your application in the right way or you will serve generic content when you shouldn't and custom (per user) content when you want generic. See this: http://dev.catalyst.perl.org/wiki/adventcalendararticles/2007/11-Making_your_Catalyst_App_Cache-friendly for some advice there. Good luck! Jay On Jun 24, 2009, at 7:02 PM, kakim...@tpg.com.au wrote: hi everyone, I just read http://www.catalystframework.org/calendar/2008/14 I have seen some mentions on http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg04620.html and http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg06552.html . Was wondering if anyone's used it and have any words of praise/ complaints? thanks k. akimoto ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: New to Catalyst questions
Right... As I've said before, I'm not interested in the super-newbie area. I don't want to teach perl. Teaching better perl practices, sure. Teaching what a sigil is and what they mean in perl... not so much. Overall, I'm interested in helping those who are new to the Catalyst platform but are already interested and those who are thinking about it but need a bit more of a clear path through the reams of documentation that is 'out there.' Jay On Feb 16, 2009, at 2:10 PM, Devin Austin wrote: I think we should also consider branching on whether someone is experienced with perl or absolutely new. Catalyst certainly isn't for the new perl programmer, so there are some basics at the very bare minimum that need to be covered in perl first. -- Devin Austin http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ 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/
[Catalyst] RFC: New to Catalyst questions
Hello, So all this 'too many choices' talk has got me thinking. I'd like to put together some more web-available information for those transitioning to catalyst from other methods. To that end I'm soliciting your thoughts on things that you found particularly hard to get a grip on when you started using catalyst. (or that you are currently having trouble with) My intent is to pick the ones that are needed most and write them up (or sponsor). My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) 2) Basic Cat toolkit - the basic pieces you will want to produce your average web app. 3) Walkthrough of creation of a simple app end to end. Any others? Jay ___ 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] RFC: The paradox of choice in web development
Hey all, Cosimo: Cool. I wanted to add that Denny de la Haye has put up perlisalive.com. He is looking for some success stories to cover. It'd be great if anyone who has some success stories / perl liveliness to share could submit them there. Jay On Feb 16, 2009, at 2:32 AM, Cosimo Streppone wrote: In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita > ha scritto: From: "David Wright" I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html I think it could be good to have a link to a "Success stories" page in the main page of catalystframework.org that also show it. We're not BBC of course, but I took some time to add the My Opera community site (developed by our team in Opera Software) to appliedstacks.com. I never heard of this site before, but since it's mentioned here I assume it's somewhat "trusted". http://www.appliedstacks.com/website/My%20Opera We use Catalyst not for the main backend stuff, but for the administration tools. We used it as a "pilot project". If you want to mention it, you're welcome to do so. -- Cosimo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I think a lot of folks make good points. I am not arguing that we do not promote things. I am arguing that A) it's not as bad as it first seems. -- and -- B) before we can promote Catalyst / Perl, we have to know where we want to position ourselves. I think it's a mistake to try to compete with Rails for the newbie. Some large percentage of newbies will never do anything more than occasional tinkering if they stick with web development at all. We have limited resources and we don't want to waste our time there. To make Catalyst accessible to the rails-like newbie, we have a TON of work to do and it's the wrong direction, in my opinion. Catalyst is a solid framework with lots of available options, I don't think we should hide that fact. I've worked with Rails, it is what led me to Catalyst in the first place. Rails is great for greenfield projects. Using Rails to replace an existing system is a nightmare. Their 'framework' requires too many adjustments to the problem space (db changes, changes to how authentication occurs, etc.) To be sure, Catalyst works easier if you can make those kinds of decisions / changes. Catalyst has the advantage, though, in the existing system space because it can be made to fit, and in most cases, rather easily. I just went through this process with a client. I had to explain why we chose Catalyst and Robert is correct here. In the enterprise, it's a hard sell. It really comes down to total cost and maintainability. I sold them on Catalyst for a few reasons: 1) There are other perl programmers out there. 2) There are other big companies using perl / Catalyst (iplayer, etc.) 3) Speed of development will increase dramatically. 4) There is commercial support outside of my organization. 5) Catalyst is maintainable and there is a focus on remaining compatible with past deployments. It was not an easy sell by any means, but the biggest issue was not Framework related, but language related. In my opinion, these are the things we need to highlight. We have two markets we are selling to, the developers and the executives / decision makers. The executives need to see the above. A failed project means their job, and that's what they are looking to ensure doesn't happen.This is the information that needs to be out there front and center. We also have to sell to the developer. This is an easy sell for the clueful, but we I agree we don't do a very good job of promoting what Catalyst can do for a developer. I think the key points here are: 1) Catalyst can do greenfield apps very easily, but can also be made to fit in to an existing system. 2) There is a ton of integration to various systems (Authentication, Databases, other sources) that save you huge amounts of time when developing. 3) There are a number of 'helpers' that make it easy to get a basic app up and running. 4) A premium is put on keeping backwards compatibility. Though Catalyst is moving forward all the time, once you build it, it will stay working. 5) We have a hugely helpful community. While they expect you to have a basic clue, beyond that they will go out of their way to help you figure things out. The irc channel should be showcased here. Perhaps even a #catalyst-help should be created with a focus on helping newbies (a web interface to #catalyst-help would be good) If we can communicate these things to newcomers (both developer and executive) we will be in good shape. Again - I don't think we should compete with Rails for the newbie, Catalyst requires some clue and we don't have the time / resources to guide people in learning perl. Again, I think if we really want to compete we should focus on what Catalyst is... and that is more flexible and capable than other systems. Jay On Feb 15, 2009, at 8:12 AM, Robert L Cochran wrote: The fact is that Oracle does not try to compete for the low end of the market with MySQL. They don't want it. They never did. Why do we? The comparison is good, but not very exact. I know companies which don't use PostgreSQL but Oracle, because Oracle is better known (because it offers discounts to the software companies that distribute it, so they have the interest of promoting it), and because Oracle offers tech support. The big companies usually want to pass the responsability to others, even if they need to pay some more. Octavian Well said. Availability of support, tons of free documentation, very flexible pricing options, plus extremely good education and certification programs, is what puts Oracle ahead. There is a huge mass of getting-started type documentation in favor of Oracle, and they make it freely available on the web. They have excellent formal certification programs. I can speak from actual experience -- I've taken several Oracle University classes. In my company, the selection of programming languages is determined by what is specified in our Enterprise Architecture. That specification does not include perl or perl-ish
Re: [Catalyst] RFC: The paradox of choice in web development
I've been watching this discussion and I have ranted my less than constructive ravings in #catalyst. My more constructive ravings are below... First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' around perl anymore... If you look at actual jobs stats: http://tiny.cc/kkcCM (or http://www.indeed.com/jobtrends?q=+perl+engineer%2C+perl+developer%2C+php+engineer%2C+php+developer%2C+ruby+developer%2C+python+developer%2C+&l= ) Perl is above all the others by some margin. It's hard to see all these other languages getting the buzz, when the one we all love is practically ignored in the press... but that doesn't make it any less good and though it's hard to tell right now, buzz does not equal real world usage. There are two problems I see, really. One problem I think David points out correctly... there is precious little 'easily accessible' means to learn about catalyst and what the conventional 'preferred' pieces are... so those that learn it are those that really need it's power, and have come searching for it. Those that are just trying to pick something and go will piss off to some more spoonfeed-easy-to- learn framework. I'm not convinced that's a bad thing. The second problem I see is that we don't seem to know who we want to market Catalyst to. We look over and see Rails and Django getting a lot of press and raves and such, and think 'I want to go to there.' Overall, though, I think that most of us who have used Catalyst for any period of time know that it is not a beginners platform. It is a powerful set of tools to solve difficult and complex problems. I think we need to take a page out of the old Unix'ers handbook. Stop looking to be as accessible to newbies as the other options, and embrace our true position... which is simply Catalyst is better. Not because it's easier to learn, and certainly not because it forces you into one (easy or not) way of doing things but because you can bend it to whatever form you need to solve whatever problem you have, even the ones that are less computer science-y and more computer-room- in-the-office-y. (though we can certainly do the former as well) In my opinion, we should embrace the fact that Catalyst is bigger, more complex, and more able. When someone says 'well, Why isn't catalyst as clear-cut and simple to use like Rails?' we should encourage them... tell them 'Go... Go play with rails... and when you grow out of it, we'll be waiting for you.' We should position Catalyst as the big-sister framework, the one whose there for you when you are ready to take on big problems that can't be solved by a bit of automatic CRUD, the ones that can't be stuffed into the channels that someone else has already dug. We should communicate an attitude of 'yes, we can solve easy problems too, but we are particularly good at solving the harder ones.' The fact is that Oracle does not try to compete for the low end of the market with MySQL. They don't want it. They never did. Why do we? Jay On Feb 13, 2009, at 4:37 PM, Octavian Râsnita wrote: I also agree with Dan. Catalyst tries to solve that problem in the RoR way - it offers a default ORM, a default template in its manual, but there are much more other perl tools which are not defined as the recommended ones. For example, HTML::FormFu is a very good form manager, but it doesn't create (yet) the javascript code for client-side validation. Instead of improving this form manager only (if it is the considered the best) to also create the JS code, other similar modules are improved, so finally becomes harder and harder to choose which is the best one, but none of them would be perfect. So finally the programmers might prefer to move to RoR or Django or something else, because it is prefered to eat a medium-good apple, than to find a very good apple after trying tens of bad-taste apples. Unfortunately I don't know if there is a solution for this, but less perl sites means that the demand for perl programmers is lower and lower each year, and this is one more reason for programmers of not beeing interested in perl. Octavian - Original Message - From: "David Steiner" > To: Sent: Saturday, February 14, 2009 12:01 AM Subject: [Catalyst] RFC: The paradox of choice in web development Hi there, here's an interesting article that dandv (from #catalyst) has posted on his wiki [1]. it explains how TMTOWTDI can be bad for people starting out in catalyst, and how compareable webframeworks (RoR/Django) deal with this. [1] http://wiki.dandascalescu.com/essays/paradox-of-choice-in-web-development i added my comments to the article, suggesting that we step up on the documentation and marketing! we need to give the layperson a easier ride in starting out with catalyst. and that requires more tutorials/ screencasts, better official documentation, and more book
Re: [Catalyst] Simplified auth configuration - input requested
I'd also be willing to include it in the DBIx::Class store dist if it's generic enough to work on anyone's db. Jay On Oct 20, 2008, at 1:41 PM, "Octavian Rasnita" <[EMAIL PROTECTED]> wrote: From: "Devin Austin" <[EMAIL PROTECTED]> Using ::Loader tends to mess some people up. I personally have written a small helper script with the options I use to update my schema code from the DB, and it makes like a million times easier. Can you share that helper? I think it could be helpful a Catalyst helper on CPAN that helps to update a database from a modified schema. If it is not on CPAN yet, can you send it to me? Thank you. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] mix authentication stores
Hello Stephan, The short answer is yes, it is possible. But you will need to do some work to make it happen. The long answer is Yee. Basically, Catalyst authentication is split into two pieces Credentials and Stores. A Store finds / holds the users. A credential is responsible for comparing the authentication information with a user (somehow) and determining whether they are who they claim to be. It is possible to use LDAP to authenticate the user, but store that user's information in the database. Unfortunately there are not any LDAP credentials. There is an LDAP store, but it expects that role information is stored in LDAP also. So what you need to do is create a credential that verifies your user via LDAP (probably using Catalyst::Model::LDAP) and then use the DBIx::Class Store to store your user information. Alternately you could create a module that subclasses (or even just wraps) the LDAP store and override the role related methods to access the database. As someone else mentioned, the Internals doc in Catalyst::Plugin::Authentication explains in detail how credentials / stores work... I doubt you'd have much trouble. Let me know if you need any more information. JayK On Tue, 2008-09-30 at 20:58 +0200, Stephan Jennewein wrote: > Hi, > > is it possible to use ldap to authenticate and dbic (a database) to handle the > user role relation ? So that it works like it resides all in one storage > backend. > If yes how do I configure that in the $application.conf ? > > Stephan > > ___ > 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/
