Re: [Catalyst] Using URL for /search/parameters: bad idea?
On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn olst...@gmail.com wrote: Hi, Consider using the query part of the URI to represent the search. Browsers are very good at bookmarking these :) What in the world is that supposed to mean? Are browsers *bad* at saving bookmarks for other kinds of URLs? ___ 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: Multiple applications (some cat based) on the same server
There's a Plack::App::FCGIDispatcher that will let you mount an external
FastCGI app as part of a Plack app, and it's possible to run PHP as an
external FastCGI app using php5-fcgi and spawn-fcgi. Maybe not the easiest
thing in the world, but totally doable. Or you could just set up a PHP app
in Apache on a high port and then point a Plack::App::Proxy at that.
On Sat, Aug 27, 2011 at 3:37 AM, Peter Edwards pe...@dragonstaff.co.ukwrote:
On 27 August 2011 08:07, Aristotle Pagaltzis pagalt...@gmx.de wrote:
If they all have Plack integration it’s trivially easy, something
like
use Plack::Builder;
builder {
mount '/cat' = $cat_app;
mount '/mouse' = $other_cat_app;
mount '/foo' = $ledgersmb_app;
mount '/' = $shinycms_app;
}
Can you integrate PHP apps with Plack?
Regards, Peter
___
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] Configuring Apache for mod_perl Catalyst and php via mod_proxy
Another solution, less ugly (IMO) than mod_proxy, is removing mod_php by setting up PHP behind mod_fastcgi. In fact, if you remove mod_perl as well by putting your Catalyst apps behind mod_fastcgi, you can have all the threading you desire. On Fri, Jul 29, 2011 at 8:15 AM, Tomas Doran bobtf...@bobtfish.net wrote: On 29 Jul 2011, at 12:25, matthew couchman (JIC) wrote: Thanks for your reply. Perhaps it was too sweeping a statement but I can only say that for my setup mod_perl works fine through Apache alone as does php but when I combine them it crashes with memory corruption errors. (At a guess), don't use the threaded MPM. Use prefork and everything will be fine. Cheers t0m __**_ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-**bin/mailman/listinfo/catalysthttp://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/** catalyst@lists.scsys.co.uk/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] error while starting my dev enviroment
On Sunday, July 10, 2011 01:36:55 AM Charlie Gonzalez wrote: Hello, I am receiving the following error message while starting my dev server enviroment: cgonzalez@cgonzalez-laptop:~/Addressit/script$ perl Addressit_server.pl -r The alias and excludes options for role application have been renamed -alias and -excludes (CatalystX::Component::Traits is consuming MooseX::Traits::Pluggable - do you need to upgrade CatalystX::Component::Traits?) at CatalystX::Component::Traits is consuming MooseX::Traits::Pluggable - do you need to update CatalystX::Component::Traits? ___ 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] DBI Models Question.
On Saturday, June 11, 2011 07:54:46 PM John Karr wrote: The mistake in my code brings up the other question (which applies to ORM models as well): How to get the model to take its parameters from appname.conf instead of having to input them directly in the model. Do absolutely nothing. It already works that way. That's what Catalyst::Model (really Catalyst::Component) provides. ___ 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] living without Apache 'deflate'
On Monday, April 04, 2011 06:11:39 PM John M. Dlugosz wrote: Since fastcgi doesn't get along with the deflate module, I've turned it off, per the installation instructions and Catalyst tutorials. But I'm wondering about SVG images. Can I pre-compress the files on disk and have the browser see the same thing as the deflate wrapper around the actual content type? That's certainly better for the server anyway, instead of deflating it on every request. For starters: you don't need to do without mod_deflate. Just install a non- broken version of mod_fastcgi (version SNAP-0811090952, from 2008, or newer). But if somehow that's not an option, you can load Catalyst::Plugin::Compress::Deflate (of course you'd also need to use Catalyst::Plugin::Static::Simple as well, instead of allowing apache to serve those files directly). Precompressing the files on disk *is* possible but there's a difficulty involved with the headers, since you can't send a deflated body without an appropriate Content-Transfer-Encoding, and you can't do it at all unless the client has sent an appropriate Accept header. Doing this right is a matter of a bit of programming, unless you can find a module that already does it for you. Andrew ___ 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] Encoding UTF8 ?
On Monday, March 28, 2011 12:50:00 PM John M. Dlugosz wrote: I don't understand why |Catalyst::Plugin::Unicode::Encoding| is necessary, based on the writup: it takes request arguments and converts them from whatever they came in to Perl's native encoding, and likewise for the response. But Perl is using UTF-8 in its strings anyway. So what's it have to do with the engine error I noticed before? What engine error you noticed before? You broke threading. ___ 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] Requesting example code for postfix and Email::Sender
On Monday, March 21, 2011 08:56:55 PM John M. Dlugosz wrote:
On 3/21/2011 1:37 PM, will trillich will.trillich-at-serensoft.com
|Catalyst/Allow to
home| wrote:
$c-stash-{*email*} = {
from = $c-config-{email_from},
'reply-to' = $c-user-email_name,
to = $c-user-email_name,
cc = join(',', @cc),
subject= $subj,
body = $message,
};
$c-forward( $c-view('Email') );
I didn't like that one (the mail view) because I don't follow: if your
function sends email instead of generating a web page, what happens to the
UA on the other end of the network who triggered that URL?
There doesn't need to be any instead of. The email view doesn't set any
response body, so the default view will still run later on by whatever means
usually runs it (i.e. RenderView).
Andrew
___
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] Requesting example code for postfix and Email::Sender
On Monday, March 21, 2011 09:12:52 PM John M. Dlugosz wrote: On 3/21/2011 4:46 PM, Dave Rolsky autarch-at-urth.org |Catalyst/Allow to home| wrote: Usually, this will be implemented as something that just writes a file to the server's mail queue, without relying on the server actually running. The server will pick it up when it runs, and will handle it from there. TL;DR - Use Email::Sender::Transport::Sendmail unless you have a really good reason to use something else. Ah, that's very good to know. However, I don't seem to have a program called 'sendmail' on the path. I had installed Postfix via the Debian package. The postfix debian package installs sendmail as /usr/sbin/sendmail which isn't on the path for non-root users by default. Not sure why, exactly. Andrew ___ 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] Quick question on forward porting versus retaining existing code
On Thursday, March 17, 2011 02:51:59 PM Joe Landman wrote: Hi folks We have a Catalyst app we've developed since about 2005 or so. We put it aside in late 2008, and haven't touched it until now. I wanted to see if it would still work (as it turns out, we can reuse this for a new project). Before we get into this in depth, are there any pointers/blog posts/articles about forward porting an application (this was pre-Moose), or whether or not the app would work without forward porting? Basically we don't want to have to redevelop everything we put into that (login/authentication, views, etc.), and simply add to the existing app with a limited set of changes to make it current would be ideal. Thanks! Joe It's the intention of the Catalyst dev team that new releases don't break existing apps. The 5.7 to 5.8 transition broke that promise *slightly* more than most releases (mostly due to the C3 MRO), but a great many apps written for 5.7 will still run without any changes on 5.8, and of the remainder, 99% will only need very small changes. Rewriting your code to make explicit use of Moose is *not* required. Just deploy the app with the current version of Catalyst and current versions of any plugins it uses, and if there are any errors or warnings on startup, use them as guidance. If you run into a nut you can't crack, please feel free to come back for advice, but you should start out by just trying to run the app. Andrew ___ 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
Run package-stash-conflicts, it will probably tell you that you need to upgrade namespace::clean. Do that. :) Andrew ___ 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] Unicode::Encoding - utf8 \xBA does not map to Unicode
On Friday, March 11, 2011 05:50:22 PM ryan lauterbach wrote: Hi, I've read some threads about unicode, utf8 and query parameters but I don't understand it enough to fix on my own, so apologies for beating a dead horse. When a URL contains a utf8 character in the query string such as ?first_name=K%E9vyn (where %E9 is é, latin small e with acute), Unicode::Encoding barfs with utf8 \xE9 does not map to Unicode. %E9 is not a UTF-8 character. A properly encoded UTF-8 URL representation of 'first_name=Kévyn' would be 'first_name=K%C3%A9vyn', which C::P::U::E will accept. $ perl -MURI::Escape -Mutf8 -le 'my $str = K\xe9vyn; utf8::encode($str); print uri_escape($str)' K%C3%A9vyn Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How to get uri_for something with a fragment?
On Sunday, March 06, 2011 05:07:25 AM John M. Dlugosz wrote:
How do I call uri_for_action and pass it the '#id' part? It's not an arg
and it's not part of the query string. This is called the fragment
identifier in the final URL.
uri_for returns a URI object, so you can always
my $uri = $c-uri_for_action(...);
$uri-fragment('id');
# Use $uri
Or, since you know that what it generates *doesn't* have a fragment you could
always just $c-uri_for_action(...) . '#id' which will be perfectly valid
(although no longer a URI object).
Andrew
___
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: Opinions on static::simple - with caching
On Tuesday, February 01, 2011 08:06:08 PM Toby Corkindale wrote: How do you find Plack at serving static files (via Middleware::Static / App::Static)? Compared to Static::Simple, and compared to native HTTPD. I guess it sits in between the two in terms of performance, but wondered how much of an improvement it was? All of them will give perfectly acceptable throughput -- even Static::Simple isn't *slow*. The real concern is that with Static::Simple or with Plack::App::File, you're tying up one of your webapp processes to serve the file -- and your webapp processes are usually fairly limited in number, and fairly memory-hungry (which prevents you from just making more). On the other hand, if you let the frontend httpd serve the file, the cost of serving a static file ranges from one lightweight httpd thread (for a threaded model) to nearly nothing at all (with an async model). Either way, it's not tying up a process that could be running Catalyst. If you're serving up a fairly small number of fairly small files, then this probably doesn't make any difference to you, but if you're serving a larger number of larger files (that will take several seconds or more to transfer) then you should probably be thinking about ways to do it outside of your webapp process. Andrew ___ 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] [ANNOUNCE] Catalyst-Runtime-5.89000-TRIAL PSGI Catalyst - first development release.
On Monday, January 24, 2011 05:12:58 PM Tomas Doran wrote: Hi It gives me great pleasure to announce the first development release of the next major version of Catalyst. This is a development release, and we need people to start trying to use it _NOW_, and to tell us about the issues you find with your real world applications. Otherwise we're going to be unable to fix those issues before a final release. There are still some known problems with the current release, and the upgrading documentation is at this stage anything but complete. However, we have been working hard to keep this release as compatible as possible with previous versions, and the documentation for upgrading will greatly improve before the final version.. Known issues: * -l argument to myapp_fastcgi.pl script is broken (this is already fixed in subversion) Actually *all* arguments to the _fastcgi script are broken in 5.89000-TRIAL (incl. -l/--listen, -n/--nproc, -d/--detach, -e/--keeperr, and -M/--manager). If you need to launch with the _fastcgi script, you will need to wait for the next trial release, or build from svn (Catalyst-Runtime/5.80/branches/psgi) or at least get Catalyst::Script::FastCGI from there. You can still test with _server.pl though, or with your own choice of Plack server and .psgi file, or test apps with Catalyst::Test and TWMC. If you maintain any modules that interface with Catalyst, give them a quick check to make sure that they don't assume the existence of Catalyst::Engine::CGI -- if they do, they will break with the removal of Catalyst::Engine::* ! Thanks, Andrew ___ 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] FastCgiServer: redefinition of a previously defined FastCGI server error when adding SSL VHost
On Sunday, December 12, 2010 09:55:33 pm Eric Berg wrote: This may be more of a FCGI question, but since it's happening with my Catalyst app, I'll ask you folks. I got my SSL cert installed and generally am configured for Apache 2.2 to serve up my site via SSL, but when I enable the FCGI config for the SSL site, I get the following error: FastCgiServer: redefinition of a previously defined FastCGI server error when adding SSL VHost [snip] I would think that the different VHosts had different contexts for FCGI, but when this config appears in both ssl and non-ssl vhosts, I get that error. Anyone have any solutions for this? No, FastCgiServer declarations are global, and the namespace for the mount points is global. Apache lets you place the config lines inside of a vhost, but that doesn't actually do anything different than if you'd placed them outside of a vhost. The good thing is that now that you know this, you probably don't have to do anything besides remove one of the conflicting lines. I find that the best organization is to have three different stanzas in three included files (in the sites-available/ directory of a debian-based config in my case, but you can adjust to taste): a file called sitename-run-fcgi only contains the FastCgiServer, FastCgiOptions, or any other config relevant to making the FastCGI available; a file called sitename contains the nonsecure vhost, and a file called sitename-secure contains the SSL vhost. Both of the latter files use the FastCGI mountpoint set up by the first file. Andrew ___ 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] Transferring control via root/auto
On Wednesday, December 08, 2010 07:31:42 am Tomas Doran wrote:
On 7 Dec 2010, at 16:11, Ben van Staveren wrote:
You want to $c-detach('end') -- unless that's the default these
days. I use this pattern a lot and the only difference I see is that
I do:
The end action will _always_ be run, there is no need to detach to the
end action.
However I'm not sure what doing $c-detach in auto will do (I guess
the same as returning 0 - i.e. stop further actions from running), but
I'm not sure - you should probably return 0 (to stop further dispatch)
rather than detaching in the auto action..
Since auto is internally just another step in _DISPATCH (Catalyst gets to it
by calling forward and everything) detaching from it behaves as you'd expect
-- the action you detach to is run, and so is end, and the current dispatch
(including the rest of auto and running $c-action) is abandoned. So, possibly
there are *cleaner* ways to deal with situations like that (often involving
Chained), but if you want to do it, it shouldn't break on you.
Andrew
___
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] Defining ARRAY in Config::General config
On Tuesday, September 21, 2010 02:52:52 am Octavian Rasnita wrote: The problem appears when the array should have just a single item, because in that case Config::General reports it as a scalar value. I don't know if there is a better way of defining a single-item array with Config::General, but I found a workaround that may work. We can use something like: With Config::General = 2.47 and Config::Any = 0.20, you can use the syntax foo [ bar ] or foo = [ bar ] to set the key foo to an arrayref containing the single value bar. The latest version of Catalyst::Plugin::ConfigLoader will ensure that you're up to date. Andrew ___ 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] Defining ARRAY in Config::General config
On Tuesday, September 21, 2010 08:30:43 am Pavel A. Karoukin wrote: On Tue, Sep 21, 2010 at 8:06 AM, Emanuele Zeppieri ema...@gmail.com wrote: On Tue, Sep 21, 2010 at 2:14 PM, Octavian Rasnita my $conf = Config::General-new( -ConfigFile = 'config.conf', -ForceArray = 1 ); How I can pass this -ForceArray to Config::General in my catalyst app? By having the current version of Config::Any installed, like I said in the first place. :) Andrew ___ 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] Instruction for SSL configuration for Apache and fastcgi
On Thursday, August 05, 2010 04:26:52 pm Kutbuddin Doctor wrote: Can someone provide apache config scripts for this situation? Do I need Port 443 for the FastCgiServer command in Apache? Will these 2 VH's use separate Session FastMmap files? Log files? No, No, and only if you ask for it. Really there's nothing to it, just do it. Write one virtualhost with VirtualHost *:80 ServerName foo [ ... other crap ...] Alias / /path/to/fcgi/ /VirtualHost and one with VirtualHost *:443 ServerName foo SSLEngine On [... other crap ...] Alias / /path/to/fcgi/ /VirtualHost ___ 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] Question on Perl versions with Catalyst
On Wednesday, July 07, 2010 06:07:39 am Joe Landman wrote: Hi folks We are redoing one of our applications, and I wanted a quick sync against which Perl versions are currently blessed. I remember that 5.10.0 did not work due to a bug in the Perl base. Are there any issues we need to be aware of for 5.12.0 or should we stick with 5.10.x (x greater than or equal to 1)? 5.12.x are all great and very solid, and 5.10.1 is fine too. Many of the versions of 5.10.0 that vendors build are also patched to remove the horrible bugs, but you should run 5.10.1+ anyway because it's better. :) Andrew ___ 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] Alternatives to DBIx?
On Saturday, April 17, 2010 06:04:58 pm John Karr wrote: In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. In my own analysis the fact that you still think that there is a thing called DBIx proves that the time and effort you've spent learning _DBIC_ is zero. ___ 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] Alternatives to DBIx?
On Sunday, April 18, 2010 12:14:55 am Eden Cardim wrote: On Sat, Apr 17, 2010 at 8:04 PM, John Karr brain...@brainbuz.org wrote: Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html) TT isn't a native approach to html, by far. In fact, it has quite a few things going against it's use to generate html. Besides what jshirley already said, it doesn't produce streamable output and once your documents get complex, it's not very easy to produce nicely indented code with it. For a native approach to html, try HTML::Zoom. Very true. In fact, ignoring the fact that it ships with a couple default plugins that know how to do HTML-compatible string encoding, TT doesn't actually know anything about HTML. It's not actually an HTML tool at all; it's a tool for pasting strings together. It's entirely possible for those strings to be HTML tags, but since TT is agnostic, it's equally good at producing completely mangled, invalid HTML as it is at producing useful HTML (note: not a value judgment, just a simple fact!) If that's what nativist means, and you're looking for a tool that takes a string-schlepping approach to *SQL*, then you need look no further than a hundred thousand shitty PHP apps ;) Andrew ___ 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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Friday 09 April 2010 09:49:24 am Evan Carroll wrote: The vulnerability was never against salted_hash. I've since learned what Crypt::SaltedHash is I just don't believe I have a reason to use it. Why would I want to use something that serializes the hash and password into one database column when I can simply store them separately? Why would you want the complexity of storing them separately when you could do it the way every other system on the planet does it? Why would you add duplicate functionality that's inferior to what it duplicates? ___ 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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Saturday 10 April 2010 11:21:27 am Evan Carroll wrote:
Also, I should point out that Crypt::SaltedHash permits the same
stupid idea of a static, non-random salt set up in the constructor.
This makes it slightly more fishy: why would you ever want to use this
module to do what I just did without it?
# salt: You can specify your on salt. You can either specify it as a
sequence of charactres or as a hex encoded string of the form
HEX{...}. If the argument is missing, a random seed is provided for
you (recommended).
That's not why that argument exists, that's not how it gets used, and that's
not how C::A::Cred::Password uses it. If you'd thought for half a second, it
might have occurred to you that that calling convention actually exists to
support exactly what you're asking for -- storing the hash and salt separately
for some bizarre reason despite that each is entirely useless without the
other.
___
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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
Please, make some more public insults. I would be even further entertained if you would make more sweeping declarations about modules you didn't even read the documentation for and have never used in your life, and submitted some more patches that duplicate functionality poorly. You can put on a show all you like for these people. If you keep it up, you can even get me to quit just to avoid your toxic presence. But I know you far too well. You'll never convince me that you're doing anything but trolling. On that topic, when did you stop being banned on this list? I'm guessing never. ___ 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] Outcome of the Security issue with hashed passwords in C:P:A:Password?
* In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * You use Catalyst::Authentication::Credential::Password. * With the hashed password_type. * And your database is compromised. * Which versions were vulnerable, and if any, at what version were they fixed, if any? All versions. hashed shouldn't be used except by those who have broken and stupid user databases; fixing it isn't possible. What we perhaps *should* do is warn when it's used, and do a better job of marking it as unsuitable for use in the perldoc. * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? * Use password_type = salted_hash to get salted hashes. * Or use password_type = self_check and a store that provides secure password handling via the user object, e.g. Catalyst::Authentication::Store::DBIx::Class w/ DBIx::Class::EncodedColumn on the user table, or Catalyst::Authentication::Store::LDAP (plus a suitable configuration on your LDAP server; some of them will allow you to do stupid things like plaintext passwords, but we can't help that). * If you have a user database that uses plain hashed passwords, start figuring out how to change over to a proper method and how to force all of your users to reset their passwords. ___ 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: Outcome of the Security issue with hashed passwords in C:P:A:Password?
On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote: On 08/04/10 22:49, Daniel Pittman wrote: ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. .. if they are using sufficiently weak passwords, such that they're present in a rainbow table? (Or do such rainbow tables contain every single possible SHA-1 value, ie. from random-looking strings that happen to correspond to the same sha-1 as the actual password?) Or weak enough to brute-force. Not using salt reduces the difficulty of brute- forcing passwords by an order of magnitude (well, some number of orders of magnitude depending on the number of users you have) because you can make a single cracking run against *all users' passwords in parallel* rather than attacking each account individually. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Security issue with hashed passwords in C:P:A:Password
On Tuesday 23 March 2010 03:17:17 pm Evan Carroll wrote: This is broken implementation. It would be if anything you said were true; fortunately it's not, and both available methods of doing salted passwords with Catalyst::Plugin::Authentication do salt entirely the correct way. Your unncecessary and condescending lectures are, however, greatly appreciated as usual. Andrew ___ 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] KiokuDB, MongoDB and the NoSQL thing
On Tuesday 02 March 2010 12:07:23 am S.A. Kiehn wrote: I have a couple of production Catalyst/DBIx::Class sites on Debian stable, and then on my personal hobby site I use local::lib to try out new things. Recently I split out my users for this site into a separate model and I thought it a good exercise to learn and use KiokuDB. It was just a couple of simple objects, users roles, but I believe I have a better understanding of how a schema-less data model would work. All I do are lookups based on ID or indexed object values, but doing any type of ordering by dates or titles is a mystery. It seems that the Search::GIN is to provide this sort of functionality, but it is under-documented and has not had an update for awhile. I do not see many posts regarding uses of KiokuDB within Catalyst so I was curious about the opinion of the community in regards to its usage. Is it still to early within development? Also, I have been reading more about the increase in the NoSQL interest, with a particular interest in the MongoDB database (it seems to be similar in some respects to KiokuDB), but I do not find Perl people in the discussion as much as others (Ruby, PHP). Are there developers in the Catalyst community who lean toward NoSQL concepts over traditional RDMS's, or is best to view as a tool to use at times? How about MongoDB? Am I being suckered by another bandwagon? Kioku is a really beautiful idea. I was hoping to use it on a recent project but unfortunately it wasn't the right fit -- one of the most common access patterns I would have to support for this app was unduly difficult in Kioku at this time so I decided to put it off. So, no real first-hand advice from me. Might I suggest hitting #catalyst and #kiokudb on irc.perl.org? I know that there's at least one person using MongoDB with Catalyst on #catalyst, so you can probably get some words of wisdom. Andrew ___ 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] FastCGI deployment - slow to complete request
On Monday 15 February 2010 10:47:45 am Steve Rippl wrote: Andrew Rodland wrote: Fix: Use a current snapshot version of mod_fastcgi. Source tarballs can be found in http://www.fastcgi.com/dist/ or if you'd like a deb, I've built http://cleverdomain.org/libapache2-mod-fastcgi_2.4.6.99~snap20081109_i38 6.deb (for Debian 5.0 i386). Andrew Thanks for providing this, but when I install it and restart apache I get wsdsis:~# /etc/init.d/apache2 start Starting web server: apache2apache2: Syntax error on line 185 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/fastcgi.load: Cannot load /usr/lib/apache2/modules/mod_fastcgi.so into server: /usr/lib/apache2/modules/mod_fastcgi.so: wrong ELF class: ELFCLASS64 failed! and I'm on a 32bit kernel (in case that's what ELFCLASS64 is referring to?) Apologies, somehow I had uploaded a bad build -- it says i386 in the filename but it was actually amd64. Fixed one is uploaded (at the same address, so just pull it again and install it again). Andrew ___ 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] FastCGI deployment - slow to complete request
On Sunday 14 February 2010 10:59:54 pm Steve Rippl wrote: If I switch this back to the built in server then the page is completed faster than I can notice and the page renders correctly immediately. Back on FastCGI and even a simple page request is taking ~10 seconds to complete (again, that html arrives straight away, but then the browser keeps spinning as if it's still waiting on something). It's a bug in mod_fastcgi that mangles the Content-Length header when it's used together with output filters (almost always mod_deflate), and there are a couple of ways to deal with it. Workaround: Disable mod_deflate, or at least prevent it from activating on anything that might come from mod_fastcgi. Fix: Use a current snapshot version of mod_fastcgi. Source tarballs can be found in http://www.fastcgi.com/dist/ or if you'd like a deb, I've built http://cleverdomain.org/libapache2-mod-fastcgi_2.4.6.99~snap20081109_i386.deb (for Debian 5.0 i386). Andrew ___ 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] myapp_fastcgi.pl does not run in background
On Tuesday 05 January 2010 06:28:36 am Emmanuel Quevillon wrote: On 01/05/2010 12:51 PM, Андрей П. Ковбович wrote: Hi, try this option: --detach Hi, That solved my problem. But it could be good to change it from the help message which is still : The correct option is --daemon; this is a bug in 5.80016. It's been fixed in svn (r12387) but not released yet. Andrew ___ 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] Accessing $self in a plugin?
On Wednesday 23 December 2009 03:40:37 am Octavian Râşniţă wrote: Hi, I use Catalyst::Controller::HTML::FormFu but in some actions I don't want to use the FormConfig attribute because it would automaticly generate and process a form, which takes much time. I want to do that only if the already generated template and data was not found in the cache. [...] First, is this correct? (or it might appear some issues). I know that the plugins are not recommended, but it is not a Catalyst plugin for public use, but only one for my app. Maybe you should extend C::C::HTML::FormFu to have the caching behavior you want, and then just use *that* as a controller base class? And if it is ok, is it possible to get $self in the plugin in order to do $self-form? Or I will need to send it explicitly using: $ff($self, 'path/to/config_file'); When running an action, the '$self' is the Controller. Outside of the action, you can get the controller for the dispatched action with $c-controller() (no argument). Andrew ___ 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] Help with weird client: POST without Content-Type
On Friday 18 December 2009 05:11:56 am Alex Povolotsky wrote:
Hello!
I'm (still) working with weird client-weird server-weird DB system, and
I need some more help from community.
Weird self-written client sends POST request without setting
Content-Type at all.
Client will be fixed, but until then I have to force Catalyst to parse
that request as if it's type was application/x-www-form-urlencoded.
How do I do that?
Here's a suggestion -- not sure if it's the best one, but it should work. In
your app class (MyApp.pm or whatever) do:
before 'prepare_body' = sub {
my $c = shift;
if ($c-req-method eq 'POST' !defined $c-req-content_type) {
$c-req-content_type('application/x-www-form-urlencoded');
}
};
The actual decision on how to parse the body is done by HTTP::Body, not by
Catalyst, so it can't easily be overridden, but using this trick we hook into
Catalyst after the headers are parsed but before HTTP::Body is invoked, and
fool it into thinking that the Content-Type actually is what you want it to
be.
Andrew
___
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] does detach cancel forward
On Saturday 07 November 2009 05:30:27 pm Andrew Rodland wrote: out, detach throws an extension that unwinds that whole stack. Being tired makes me type words that *sound* similar to the one I meant. Exception. Not extension. Exception. :) Andrew ___ 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] does detach cancel forward
On Saturday 07 November 2009 01:08:33 pm Steve Rippl wrote: it's just that I had started thinking in terms of nested flow control because that's what I wanted (wishful thinking...). I thought perhaps each forward created a separate nest/level I could detach out of and previous forwards were remembered, but obviously this isn't the case. No, this *is* the case, 100%. Forward is nothing more than a function call, so you can nest it and you get a call stack. It's just that, as I pointed out, detach throws an extension that unwinds that whole stack. Andrew ___ 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] auto method never triggered
On Sunday 01 November 2009 08:07:32 pm Julien Sobrier wrote:
Thank you
Shoudl It put __PACKAGE__-config-{namespace} = ''root;, or simply remove
this line?
You should leave it how it is in the root controller, and remove it in the
admin controller.
___
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] Debian recommendation
On Tuesday 27 October 2009 05:18:32 pm Evan Carroll wrote: I simply disapprove of taking something knowingly breaking it, and publishing it as if nothing happened. Then I suppose it's a good thing that no such thing happens. ___ 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::Test configuration questions
On Monday 26 October 2009 04:51:57 pm Evan Carroll wrote: My latest project, a Craigslist posting tool, is configured through the applications yaml conf file. I'm looking for a way to test based the conf file with Catalyst::Test. Any idea of how to accomplish this? You're gonna need some http://dl.getdropbox.com/u/129905/specialized-hardware.jpg for that. Andrew ___ 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: Catalyst benchmark 5.7 VS 5.8
On Monday 28 September 2009 09:31:13 pm Fayland Lam wrote: Toby Corkindale wrote: Fayland, I was looking at the benchmarks that you linked, and was just wondering which version of Perl you're running against? (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance.. although I'm sure it's been patched by now? ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ ) Thanks for your update. but it doesn't help on the benchmark since they are run on the same condition. so 5.7 is really better than 5.8 under siege. That doesn't follow. If your perl is broken and very slow at doing something that 5.8 does much more often, then 5.8 can be slower for you without being slower for everyone else. I have a real app and a suitable test system at hand -- I'll run some benches of my own and at least add a few more data points to the mix. Andrew ___ 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] FastMmap.pm error while writing sessions file to shared file system
On Wednesday 05 August 2009 01:27:11 am gutta wrote: could anyone let me know what the problem here? The problem is that what you're trying to do is impossible. You can't mmap a file on a non-local fs, so Cache::FastMmap won't work. I wouldn't expect any other file-based cache (or SQLite) to be consistent either. If you need to distribute your session store across multiple backend machines you want a DB store or memcached. Andrew ___ 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] passwordless LDAP authentication
On Monday 27 July 2009 04:38:35 am Rodrigo wrote: Hi all, I'm using Catalyst::Authentication::Store::LDAP to authenticate users, but now I need to allow some of them to single-signon without a password, like this: [...] I'm looking at the authentication internals and it seems to be missing a per-user flag to disable password checking. Only a global realm-based password_type='none' exists. Am I correct? That's not auth in general, it's Credential::Password. You can write your own credential that implements your own policy and have it do whatever you like. To make matters worse, LDAP::User::check_password also checks user roles since it needs the password to bind to the ldap server. That could make it more difficult to implement a passwordless flag at any level on the authenticate chain. Store::LDAP has an option for whether or not to rebind as the given user when doing role searches. If it's off, and if your LDAP permissions are set appropriately, you shouldn't need the user's password at any phase. Andrew ___ 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] More up-to-date version of Perl 5.10 ...
On Monday 20 July 2009 02:42:51 pm Kiffin Gish wrote: Hi there. Installed Catalyst and at the end it said that because of a bug in Perl 5.10 I need to update to a newer version. Which version do you recommend that is the most stable for Catalyst? If you build your own perl, then take 5.10.0 and patch it for RT#488088 before you compile. If you get perl from a vendor, then you should hope that they patched their version a year ago, and if not you should start yelling loudly at them. Either way, 5.10.0 (until 5.10.1 arrives). Andrew ___ 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] more description for FAST CGI deployment in catalyst cookbook?
On Wednesday 15 July 2009 06:23:24 pm kakim...@tpg.com.au wrote: Again, my question is, where do I put the configuration above in? apache.conf ? httpd.conf? Doesn't say :( Wherever it needs to be for your setup; apache configurations differ quite a bit by vendor, and this is the Catalyst cookbook, not the Apache instructions. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] how to implement Transactions (over different db tables) in a Catalyst project
On Monday 06 July 2009 05:37:49 pm kakim...@tpg.com.au wrote: Did you even look for this in the manual? http://search.cpan.org/~ribasushi/DBIx-Class-0.08107/lib/DBIx/Class/ Storage.pm#txn_do If not, why not. If so, how is this not clear? Well, it's really clear now . I suppose someone has updated the documentation since I posted this thread up. That's the same version of the same doc as you mentioned in the first post of the thread :) Andrew ___ 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] Potential query string pollution vulnerability?
On Tuesday 16 June 2009 04:11:19 am Tobias Kremer wrote:
To me, this never looked like a potential security threat because
$c-req-param('name') is correctly inserted/quoted via bind
parameters, right? Well, let's see what happens, if we pollute the
query string a bit:
/crashme?name=Fooname=Bar
Using $c-req-param for this kind of purpose (or, if you ask certain people,
for any purpose) is discouraged, and has been discouraged as long as I can
remember, for this reason. Use $c-req-params and validate your input.
(Incidentally, if you'd used $c-req-params-{name} the behavior you would
have gotten would have been WHERE name='Foo' OR name='Bar' which can be a
really useful behavior straight out of the box -- but the point stands that
you have to know what your data is, know what your data needs to be, and make
sure that the two are reconcileable before you do anything :)
Andrew
___
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] Notes on installing lighttpd and FastCGI for Catalyst
On Saturday 06 June 2009 04:04:08 am kakim...@tpg.com.au wrote: hi guys, I'm facing some problems with http://dev.catalyst.perl.org/wiki/deployment/lighttpd_fastcgi. This message looks oddly familiar. Andrew ___ 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: error when using Authentication::Store::Minimal
You shouldn't be using the login method to begin with, you want authenticate. Pay less attention to the book (which has very little to do with anything) and more to the docs. Andrew ___ 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] Looking for a working example using DBIC and Authentication
On Thursday 28 May 2009 07:36:29 pm Simon Baird wrote: Thanks for the advice. I might start fresh and see if I can pinpoint where things went wrong. Ok, so just now I have: * Googled and ended up here: http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7000/lib/Catalyst/Manua l/Tutorial/Authentication.pod Google is not to be trusted: that's 3 years old. Its advice was reasonably good three years ago, but not so much today. The current version is at http://search.cpan.org/~hkclark/Catalyst- Manual-5.8000/lib/Catalyst/Manual/Tutorial/05_Authentication.pod . Andrew ___ 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] Mason + DBI + Catalyst?
On Monday 25 May 2009 05:35:45 pm Daniel Carrera wrote: Is there any good documentation for Catalyst that is based on Mason? Catalyst is Perl. Catalyst apps are Perl apps. All the docs you need on Mason are in perldoc Mason and all the docs you need on DBI are in perldoc DBI. The info you need on how things get glued together is in perldoc Catalyst::View::Mason and perldoc Catalyst::Model::DBI. And incidentally, you're wrong about DBIC. As soon as you get into queries for related tables, DBIC will be reducing the amount of code you need to write (and the number of potential screwups) tenfold. Then throw in bonus features like txn_do and the deployment goodies... it ends up being worthwhile pretty often ;) Andrew ___ 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] Strange RenderView error
On Sunday 24 May 2009 03:51:47 pm Ivan Wills wrote: If I understand it correctly the :Arg attribute takes extra path parameters and converts them to method parameters so I can't see why the problem would occur. 1. That happens by default. 2. :Args(0) says that there are _no_ extra args on the path and the dispatcher shouldn't match them. 3. :Arg(0) does nothing (at least, it should do nothing) because it's not :Args(0). Andrew ___ 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] Who wants to be rid of the Unknown Error w/attributes bug on 5.10?
On Monday 11 May 2009 05:45:01 pm Jonathan Rockway wrote: Or, you can use Debian, which fixed this bug in its Perl a while ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488088 Not everyone uses Debian, and I, for one, would much rather be able to tell people get 5.10.1 than to have to explain what patch is or try to convince them to switch their operating system. A fix from upstream is long overdue. :) Andrew ___ 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] Forward to view question
On Wednesday 06 May 2009 09:01:43 am Dennis Daupert wrote:
On Tue, May 5, 2009 at 7:24 PM, Tomas Doran bobtf...@bobtfish.net wrote:
my $output = delete $c-res-{body};
opem(FH, file) or die;
print FH $output;
close(FH);
will do what you want...
There are some things that aren't so obvious to me. Where would I place the
code represented in your snippet? I can't just hang it out in the main
body of package hde::View::TTprint,
In that example you don't *have* a View::TTprint. Or if you do, it's just
another subclas of C::V::TT with a different config and search path. No
overloading, no OUTPUT. You forward to the view, it writes into $c-res-body
like it always does. You take the data out of $c-res-body and write it to a
file, then null out $c-res-body so that RenderView will fill it in later
using your default_view.
Andrew
___
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::Engine::HTTP taking very long
On Monday 20 April 2009 04:35:05 am Terence Monteiro wrote: I'm getting very high times when running my Catalyst application in standalone mode. I used Devel::NYTProf and zeroed in on a few subs in Catalyst::Engine::HTTP which take long: The times for accept are because accept is the function that waits for a new incoming connection -- not a bug, 100% expected. The time spent in inet_ntoa is your system DNS resolver choking while trying to reverse-lookup the source IP address of the request. Most likely situation: you're using RFC1918 addresses and your network is set up improperly to do DNS for these. If you can't fix this, hosts file entries might alleviate the problem. Andrew ___ 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] Local action in controller not mapping to template (retry)
On Monday 20 April 2009 08:42:16 am Anne Brown wrote:
t0m,
My development environment is a Windoze VISTA 64-bit OS, running Apache
2.2.11,
and perl 5.8.8 and plain old CGI. My other development environment is the
same except for a Linux OS and is having the same problem.
You said that :Private makes an action not dispatchable, however, the line:
sub index : Private {}
in my root controller renders the main template.
That's legacy and you shouldn't do it. It should be
sub index :Path Args(0) { ... }
Having index be a private action made no sense, which is why nothing does that
anymore -- the helper scripts don't generate it, and the tutorial doesn't show
it. It only still _works_ so that old apps aren't broken.
Andrew
___
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] about catalyst authentication
On Saturday 18 April 2009 01:28:30 am Malloy wrote: After restart apache, user must login again. I find $c-user_existsis not true. Why? Because you're using Session::Store::FastMmap and the session cache file didn't exist before your app started, so Cache::FastMmap deletes it on exit? Andrew ___ 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] Including a submenu
On Monday 06 April 2009 10:06:52 am toppe...@gmail.com wrote: However, when I load the page,I get the following error: Couldn't render template file error - /menu.tt2: absolute paths are not allowed (set ABSOLUTE option) Am I going missing something obvious, or going about this in the wrong way? Set 'page' to something that doesn't start with a slash? Andrew ___ 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] Browser still waiting after completed transfer
On Saturday 21 March 2009 04:12:48 pm Christian Lackas wrote: Hi Everybody, currently have a strange problem with a Catalyst app, which I developed on Gentoo Linux and now try to deploy on Debian/Lenny. On Debian, the browser (Firefox) waits a couple of seconds (~10s) after it has already received all content (as shown by Firebug), apparently still waiting for something (but Firebug does not show anything else). Is it possible that I get a wrong Content-Length header and thus the browser waits for the web page to be completely transferred too long? Don't see this on Gentoo. Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 PHP/5.2.6-1+lenny2 with Suhosin-Patch This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi Module = Catalyst::Runtime (MRAMBERG/Catalyst-Runtime-5.71000.tar.gz) Are you running mod_deflate as well? There's a known bug in mod_fastcgi that causes exactly this kind of problem if mod_deflate is in front of it. It can be solved by disabling mod_deflate or ensuring that it won't process any content that mod_fastcgi serves, or by building and installing mod_fastcgi- SNAP-0811090952.tar.gz Andrew ___ 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] Accessing a Controller from ~/script
On Monday 09 March 2009 12:54:34 pm Dermot wrote: 2009/2/19 Kieren Diment kie...@diment.org: On 19/02/2009, at 11:58 PM, Dermot wrote: Wow! that works but I am not sure where ACCEPT_CONTEXT comes into it. That'd be if you needed to pass stuff from $c into the model to get it working properly. I'd like to allow my stand alone model access to the configuration values contained in MyApp-config. It seems like the tidy way to do things. Does the ACCEPT_CONTEXT method allow me to do this? Is there some kinda SUPER way I can grab config and make an accessor of it? Your Model has its own bit of config space, and this config info is passed to its constructor. The advisable thing to do here is to have your config there, and have your Model class pass that info along to your backend model class. If you need some more complex interaction then you can have more glue in your Model class (and ACCEPT_CONTEXT as necessary), but the goal here is not to influence your backend class. If the backend class depends on any class with 'Catalyst' in the name, or it depends on your app being around so it can rummage around in the config structure, then you can't really instantiate it outside of Catalyst, so what's the point of splitting it out? Loose coupling is the word. Andrew ___ 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] Base URI breakdown
On Friday 06 March 2009 09:02:01 pm Trevor Phillips wrote: In a Catalyst app, I need to break down the base request URL to extract hostname, port, etc separately. I could do this with a regexp on $c-request-base, or I could use the URI perl lib, but is there already a way to access this within Catalyst? The docs say that $c-request-base is a string only, whereas I'd like to access separately bits like $c-request-base-host and $c-request-base-port. $c-req-base is a URI object under all of the Engine types that I'm aware of. The docs don't promise this, but they don't say it's not either. Anyway there's no reason you couldn't do URI-new($c-req-base) which will be a perfectly good URI object whether base is a URI or an unblessed string. :) Andrew ___ 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] catamoose now or when?
On Wednesday 04 March 2009 07:52:56 pm Elliot Finley wrote: Hello, I'm starting a new web app project that I need to deploy in about 2 months. There will be ongoing updates to this app as time goes by. I'm new to catalyst/moose/dbic but a long time Perl hacker. Considering the above, would I be better off starting with 5.71 or 5.8? The 5.7 - 5.8 transition should require little to no rewriting of application-level code, so I'd suggest sticking with the released 5.7 for serious production. If you're inclined, though, and you have the resources, you could set up a box with 5.8000_06 in parallel for testing -- that would let you know about any hassles you might have upgrading in the future, as well as letting you contribute bug reports on 5.8 to avoid said hassles. :) Andrew ___ 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] Requirements for Catalyst
On Saturday 21 February 2009 05:04:54 pm Jonathan Rockway wrote: * On Sat, Feb 21 2009, Octavian Râşniţă wrote: Hello, It is very clear that a Catalyst app can't run on a shared host, but it requires either a dedicated server or a VPS. I am searching for web space providers that offer VPS and I've seen that they use to set their tariff plans mainly on the guaranteed memory, but I don't know which would be the necessary memory for a VPS that runs an OS like Fedora or CentOS, Apache, Perl and Catalyst. Could be 256 MB of memory enough? Or 512? Or I would need 1 GB or more if I would like to run a Catalyst app? We run lots of Catalyst apps on the smallest Linode. I think they give us something like 340M of RAM. This is enough. I use a 512M Slicehost for jrock.us, which runs my mail server and a few Catalyst applications. Anyway, nearly every VPS provider I know of lets you add more memory easily. Buy the small one, and if you need more memory, upgrade. Seconded. I run prod stuff for $WORK on Xen VMs with 512MB of RAM. Light-duty stuff should work well enough on 256MB and Linode's 360 deal is just about ideal. And any _good_ provider should let you instantly add more RAM with nothing more than a reboot, and prorate the bill appropriately, so growing shouldn't be a huge source of concern. Andrew ___ 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
On Thursday 19 February 2009 09:12:36 am Matt Pitts wrote: In today's world of software that is cross-platform and OS agnostic at its core, Perl 5 is showing its age. Still love it though. This isn't as much a Perl problem as it seems to be -- it's the rule all around that writing code that works on _everything but Windows_ is ten times easier than writing code that works on everything including Windows. Perl is just in a unique place to show this. In C, which is hardly more than a portable(-ish) layer on top of assembler, and which has a small standard library, code isn't portable at all without significant work (and even still, Windows is usually the hardest target to hit.) In Java, portability is considered paramount, so OS facilities are exposed through thick compatibility layers or else not at all. Perl sits in the middle ground. Sufficiently pure perl code will run on a million and one platforms, but at the same time Perl was never afraid to expose OS facilities (like stat or SysV IPC) more or less directly, to allow more powerful code. This has made it easy to write code that, even though it doesn't use XS as all, is platform-specific enough to crash and burn on windows. But if it's a shortcoming in Perl, how do we fix it? By taking all the goodies away from the Unix folks so everyone has to write to the least common denominator? ___ 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
On Sunday 15 February 2009 03:04:04 am Dan Dascalescu wrote: 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 Perl is above all the others by some margin. Short version: that graph is misleading. Click the Relative link. Longer version: Yes, Perl is above the rest by some margin, thanks to its history. There are existing Perl applications that need to be maintained, and some momentum that keeps the demand for Perl jobs going. But click the Relative link in the graph, and see the percentage growth for Ruby jobs. It skyrockets when compared with both PHP and Perl. Of course it does. Look at the absolute graph. The 2005 figure for Ruby is, to within the resolution of the graph, zero. It's not hard to have ten thousand percent growth from zero! The absolute graph would have you believe that the huge threat is from Ruby which has gone from zero to perhaps a quarter as big as perl, while the absolute graph makes it clear that the real competition is from the black line representing PHP. And yet if everyone were to abandon PHP tomorrow in favor of Perl it *still* wouldn't make a blip on the relative graph. Why? Because the relative graph is braindead. Andrew ___ 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] DBIx makes Catalyst startup painfully slow
On Tuesday 10 February 2009 04:53:32 am Neo [GC] wrote: Hello people, I'm working on a rather big CRM system using Catalyst with all bells and whistles. For database, we use DBIx::Class::Schema and this drives me crazy... Apart from Catalyst being really resource hungry, the startup time for the application (testserver oder fastcgi) is ok, about 4 seconds on my development-system (CentOS on VMware Fusion on MacOS X Leopard, Core 2 Duo 2.2GHz). It's not perfect for developing, but it is completely acceptable. But as soon as I activate my DBIx schemas, the startup time multiplies: 12 seconds with my first (and most important) schema, 25 seconds when using all schemas. Just to be clear, since you mention startup time, are you using a fixed DBIx::Class::Schema, or DBIx::Class::Schema::Loader at runtime? If the latter, a slow startup is to be expected, and the solution is largely don't do that then. If the former, then I suspect Nigel has you headed in the right direction. Andrew ___ 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] template design issue: varibales stand-alone components
On Wednesday 04 February 2009 05:25:41 pm Gene Selkov wrote:
On Wed, 4 Feb 2009, J. Shirley wrote:
The Catalyst method is quite simple, since it tries to adhere to the
MVC design patterns.
You would not set the variable in your templates, instead in the
controller.
sub action_name : Local {
my ( $self, $c ) = @_;
$c-stash-{surname} = $c-model('LDAP')-get_ldap_surname($id);
}
Then your template gets 'surname' and you can just do:
Hello % $surname %!
I understood as much. The problem I am grappling with is the complexity of
the web pages I have to present, with many different states and
transitions. There is no way I can code for that with a single template.
There's no single template implied. By default you're probably going to have
a template per-action, though that's completely up to you, and TT provides
tools such as WRAPPER, INCLUDE, and BLOCK to let you organize and reuse your
code. I'd suggest spending a little time with the Template::Manual as well as
having a look at some real-life Catalyst apps.
Andrew
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI
On Tuesday 03 February 2009 11:45:07 am Jonathan Rockway wrote: * On Mon, Feb 02 2009, Andrew Rodland wrote: I've thought over the problem and decided that the only appropriate place for a fix is in Engine::FastCGI. A srand anyplace else (including the app code) would run either too early (not solving the shared state problem) or too late (re-seeding on every request is Bad.) Wait, is there a reason why we can't do this in FCGI::ProcManager instead? This is something that affects everyone using FCGI, not just Catalyst. A reasonable question. I'll see if I can get gbjk's thoughts on the matter. Andrew ___ 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] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI
Due to the way FastCGI does its business, when running as an external
FastCGI, the perl interpreter and the Catalyst app are initialized before the
FCGI process manager does its forking. Since modern versions of Perl seed
rand() eagerly on startup, this leads to all of the FastCGI children
inheriting the same RNG state, and very nonrandom behavior (such as CAPTCHAs
that appear to get stuck).
I've thought over the problem and decided that the only appropriate place for
a fix is in Engine::FastCGI. A srand anyplace else (including the app code)
would run either too early (not solving the shared state problem) or too
late (re-seeding on every request is Bad.)
Attached is a patch that does an srand in each child immediately after
invoking pm_manage, if we are running our own process manager. I can't think
at the moment how to write a test for it, but a behavior test shows that it
completely solved the randomness problem on my end, and I ran an instrumented
version to make sure that it's not srand'ing more than once per child -- it's
not. Patch applies against Catalyst-Runtime/5.80/trunk and
Catalyst-Runtime/5.70/trunk (with negligible fuzz).
Index: lib/Catalyst/Engine/FastCGI.pm
===
--- lib/Catalyst/Engine/FastCGI.pm (revision 9173)
+++ lib/Catalyst/Engine/FastCGI.pm (working copy)
@@ -130,6 +130,8 @@
$self-daemon_detach() if $options-{detach};
$proc_manager-pm_manage();
+# Give each child its own RNG state.
+srand;
}
elsif ( $options-{detach} ) {
$self-daemon_detach();
___
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: Detach won't detach?
On Tuesday 27 January 2009 05:33:46 pm Jonathan Rockway wrote:
* On Tue, Jan 27 2009, pie3...@comcast.net wrote:
Why not
sub auto :Private {
my $c = pop;
return user_logged_in || $c-res-redirect( ... );
}
Because now the correctness of your application depends on undocumented
behavior (the return value of $c-res-redirect).
|| 0 doesn't fix that any. Did you want 0? :)
Andrew
___
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] Tool for rendering web pages consistently though time ?
On Wednesday 21 January 2009 07:10:15 pm lanas wrote: That would be over two years. This is for the making and updating of a user guide. Currently the procedure is to take screenshots but then, it so happen that the original workstation witht he original resolution and fonts no longer exists, so the screenshots of the web pages are no longer exactly the same. It'd be possible to dedicate a do not touch workstation for that purpose only but I'm looking for a more elegant solution which do not rely on any workstation hardware/resolution/fonts. A unix box, Xvfb, firefox, a page saver extension, and a little automation? Then all the config details are under your control, and the hands off bit becomes less of a factor. Just a thought. Andrew ___ 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] [Announce] Catalyst::Runtime 5.7099_04. IMPORTANT; PLEASE TEST!
On Tuesday 13 January 2009 08:31:07 pm Greg Matheson wrote: On Tue, 13 Jan 2009, Oleg Kostyuk wrote: 2) added ru and ua translations (see in attachment) So that's where those messages are! Here's some non-native Chinese and Japanese ones. I don't know if it was a mistake or a really subtle joke, but all non-Latin text in your email was sent as question-marks. Andrew ___ 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] [Announce] Catalyst::Runtime 5.7099_04. IMPORTANT; PLEASE TEST!
On Tuesday 13 January 2009 09:03:24 pm Oleg Kostyuk wrote: 2009/1/14 Andrew Rodland arodl...@comcast.net: On Tuesday 13 January 2009 08:31:07 pm Greg Matheson wrote: On Tue, 13 Jan 2009, Oleg Kostyuk wrote: 2) added ru and ua translations (see in attachment) So that's where those messages are! Here's some non-native Chinese and Japanese ones. I don't know if it was a mistake or a really subtle joke, but all non-Latin text in your email was sent as question-marks. You mean my email also, or only email from Greg? Yours was just fine (except it was mangled when Greg quoted it). Andrew ___ 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 modperl - child process segmentation fault
On Monday 08 December 2008 02:20:38 am Terence Monteiro wrote: How can I find out the mysql client libraries DBD::mysql and mod_php are linked with? What you say is possible because I upgraded DBD::mysql from the latest debian sources in unstable, but not (yet) mod_php. But I don't understand why mod_php should matter. (answering just this part) because, assuming you use mod_php, and your PHP is built to support mysql (it almost always is), then PHP will be linked against libmysqlcient, and apache will link in mod_php at runtime, bringing in mysql by reference. Then your mod_perl app uses DBI, which also dlopens libmysqlclient, and hilarity ensues. To answer your question of how?, I'd suggest ldd'ing the appropriate components -- mod_php.so and auto/DBD/mysql/mysql.so. ___ 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] Advent calendar
On Monday 01 December 2008 07:22:48 pm Dan Dascalescu wrote: And of course I forgot the URL: http://www.catalystframework.org/calendar I'd like to suggest hosting the Advent Calendar articles on the Catalyst Wiki: http://dev.catalyst.perl.org/wiki/adventcalendararticles When you have a project with an internet presence, and you don't have time to do a proper job, you put up a wiki and hack it into doing what you want. When you have a bunch of web developers, and your project is web development, and you need something done that's really not wiki-ish at all, you _do it right_. If Advent sucks (yes, organization could be better, and markdown has its pros, as well as its cons that you seem to be ignoring), then help improve it. Schlepping it onto the wiki has its own set of problems, and isn't in itself a _solution_ to anything. Andrew ___ 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] OT Apache question
On Thursday 27 November 2008 08:45:16 pm Jesse Sheidlower wrote: However my document root is at /usr/local/www/data, which obviously does not include /usr/local/www/modules. So, if I try to follow the Static::Simple suggestion of adding, say, Location /Incomings/static SetHandler default-handler /Location this obviously won't work because /Incomings/static isn't in fact under my document root, it's in the filesystem at /usr/local/www/modules/Incomings/root/static/. Trying this just gives me 404's for all of the static stuff (CSS, images, JS). How do I configure Apache to serve these files, without reorganizing what is by now a rather complicated directory structure? Alias /incomings/static /yada/yada/root/static Location /incomings/static SetHandler default-handler /Location ___ 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] Making subrequests in views
On Sunday 23 November 2008 03:29:11 am Alexander Tamm wrote: Hi, I'm pretty new to Catalyst and new to this mailing list. In other words, my apologies if this question has been frequently answered or if I've missed the relevant documentation. My basic setup is a Catalyst application running under FastCGI, using View::Mason for my views. I need to include a navigation component in most - not all - views, so I'm thinking about what strategy I should use to populate the stash with the correct data. As I see it, I have at least three options, but I'm not sure how smart they are. 1) I could always populate the stash in auto() and call the corresponding Mason component when needed. This means fetching some data even if it isn't needed. This version, except that instead of doing it in auto, you do it in end or in an ActionClass, only when you know you're going to need it (that is, you're actually sending back a page that includes the menu, and not a redirect or a downloadable file or whatever else). Andrew ___ 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: Feature Request: Parameter Junctions
On Thursday 30 October 2008 03:23:40 am Oleg Kostyuk wrote: 2008/10/22 Aristotle Pagaltzis [EMAIL PROTECTED]: I outlined a proposal a long time ago of two different methods like the current `param`, one which always returned a single value (the last one if there are multiple) and one which always returned an arrayref. Then there could be no confusion and code would always get exactly what it was written to expect. Matt agreed but punted to volunteers, and none stepped up, me included, so it has yet to happen. Could you please give link to your original thread ? I think perhaps this was the thread -- http://thread.gmane.org/gmane.comp.web.catalyst.general/15862 Andrew ___ 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] PDF creation in Catalyst?
On Wednesday 22 October 2008 01:08:45 pm Kirby Krueger wrote: Somewhat less snippishly, I've been trying to figure out the state of PDF generation from Catalyst. I don't need to do anything super fancy - mostly get a report so it can print on paper that's perforated into thirds, without worrying about browsers, telling users how to turn off browser print header/footer lines, and the like. I've seen several options: Yeah, PDF generation is just unpleasant IMO, Catalyst or not. None of the tools available in Perl are high-level enough to make me happy. $WORK has a system using Apache FOP for report generation. It works, and the output is good, but creating the templates is a grind, and the code to invoke fop is ugly (and it's Java)... and that's the best thing I know of ;) Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [PATCH] [RFC] Override base URI
On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote: 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 do that. Without this functionality it would be hard to do SSL accelerators and such properly. I was trying to be clever and make it so that you only needed one config key in the case where your secure and nonsecure bases only differed in the scheme. I guess it was too clever. I'll go back and make them entirely separate -- it'll be less code anyway. :) Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [PATCH] [RFC] Override base URI
On Friday 10 October 2008 02:04:44 pm Andrew Rodland wrote:
On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote:
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 do that.
Without this functionality it would be hard to do SSL accelerators and
such properly.
I was trying to be clever and make it so that you only needed one config
key in the case where your secure and nonsecure bases only differed in the
scheme. I guess it was too clever. I'll go back and make them entirely
separate -- it'll be less code anyway. :)
New version based on input from t0m and jayk and karpet.
lib/Catalyst/Engine/CGI.pm | 23 +++--
t/unit_engine_cgi.t| 86 +++
2 files changed, 105 insertions(+), 4 deletions(-)
Andrew
Index: t/unit_engine_cgi.t
===
--- t/unit_engine_cgi.t (revision 0)
+++ t/unit_engine_cgi.t (revision 0)
@@ -0,0 +1,86 @@
+use strict;
+use warnings;
+
+use Test::More tests = 6;
+use URI;
+
+use_ok('Catalyst');
+
+my $http_request = Catalyst::Request-new( { secure = 0 } );
+my $https_request = Catalyst::Request-new( { secure = 1 } );
+
+$ENV{HTTP_HOST} = 127.0.0.1;
+$ENV{SERVER_PORT} = 80;
+$ENV{SCRIPT_NAME} = '/catalyst.fcgi';
+
+my $context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'http://127.0.0.1/catalyst.fcgi/pants',
+ 'Base URI'
+);
+
+$context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = http://127.1.2.3/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'http://127.1.2.3/pants',
+ 'Overriden base URI'
+);
+
+$context = Catalyst-new( {
+request = $https_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri_secure} = https://127.1.2.3/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'https://127.1.2.3/pants',
+ 'Overriden base URI for HTTPS'
+);
+
+$context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = https://127.1.2.3/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'https://127.1.2.3/pants',
+ 'Override nonsecure base URI to HTTPS'
+);
+
+$context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = dev.catalyst.perl.org;
+$context-setup_engine('CGI');
+eval {
+ $context-prepare_path;
+};
+
+like (
+ $@,
+ qr/Invalid/,
+ 'Handle invalid override_base_uri'
+);
+
Index: lib/Catalyst/Engine/CGI.pm
===
--- lib/Catalyst/Engine/CGI.pm (revision 8518)
+++ lib/Catalyst/Engine/CGI.pm (working copy)
@@ -160,12 +160,27 @@
$c-request-uri( bless \$uri, $uri_class );
# set the base URI
+
+my $base_uri;
+
+if (defined $c-config-{override_base_uri} ! $c-request-secure) {
+ # Use an overridden base URI.
+ $base_uri = $c-config-{override_base_uri};
+} elsif (defined $c-config-{override_base_uri_secure} $c-request-secure) {
+ # For HTTPS requests.
+ $base_uri = $c-config-{override_base_uri_secure};
+} else {
+ # Use the server-provided (default) base path.
+ $base_uri = $scheme . '://' . $host . $base_path;
+}
+
# base must end in a slash
-$base_path .= '/' unless $base_path =~ m{/$};
+$base_uri .= '/' unless $base_uri =~ m{/$};
+# Ref. URI.pm
+$base_uri =~ /^([A-Za-z][A-Za-z0-9.+-]*):/ or die Invalid base URI;
+my $base_scheme = $1;
-my $base_uri = $scheme . '://' . $host . $base_path;
-
-$c-request-base( bless \$base_uri, $uri_class );
+$c-request-base( bless \$base_uri, URI::$base_scheme );
}
=head2 $self-prepare_query_parameters($c)
___
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] [PATCH] [RFC] Override base URI
mst I've put something like that in a sub prepare before now
mst we should maybe have a config option to override base
mst patches would be welcome :)
Here's an attempt. I've never really hacked on the core before, so please go
easy. Also I know that POD isn't included, but that's because I can't figure
out where it belongs. I'll write it, given a place to put it.
Anyway, this is a patch to create a pair of config keys tell
Engine::CGI ignore what the server thinks the base path is, and use these
instead. It's useful in the case that someone has their application
port-forwarded, load-balanced, proxied, etc. through some sort of device that
doesn't set X-Forwarded-Host.
How it works: If no config is provided, life continues as it always has. If
the request is HTTP and $c-config-{override_base_uri} is set, we use that
as $c-req-base. If the request is HTTPS and
$c-config-{override_base_uri_secure} is set, we use that as $c-req-base.
If the request is HTTPS and override_base_uri_secure isn't set, but
override_base_uri is, we use override_base_uri and switch its scheme to https
(hopefully it doesn't have a port).
Patch against Catalyst-Runtime/5.80/trunk which I hope is the right thing.
Comments appreciated,
Andrew
Index: t/unit_engine_cgi.t
===
--- t/unit_engine_cgi.t (revision 0)
+++ t/unit_engine_cgi.t (revision 0)
@@ -0,0 +1,71 @@
+use strict;
+use warnings;
+
+use Test::More tests = 5;
+use URI;
+
+use_ok('Catalyst');
+
+my $http_request = Catalyst::Request-new( { secure = 0 } );
+my $https_request = Catalyst::Request-new( { secure = 1 } );
+
+$ENV{HTTP_HOST} = 127.0.0.1;
+$ENV{SERVER_PORT} = 80;
+$ENV{SCRIPT_NAME} = '/catalyst.fcgi';
+
+my $context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'http://127.0.0.1/catalyst.fcgi/pants',
+ 'Base URI'
+);
+
+$context = Catalyst-new( {
+request = $http_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = http://127.1.2.3/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'http://127.1.2.3/pants',
+ 'Overriden base URI'
+);
+
+$context = Catalyst-new( {
+request = $https_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = http://127.1.2.3/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'https://127.1.2.3/pants',
+ 'Overriden base URI for HTTPS'
+);
+
+$context = Catalyst-new( {
+request = $https_request,
+namespace = 'yada',
+ } );
+$context-config-{override_base_uri} = http://127.1.2.3/;;
+$context-config-{override_base_uri_secure} = https://127.1.2.4/;;
+$context-setup_engine('CGI');
+$context-prepare_path;
+
+is (
+ Catalyst::uri_for( $context, '/pants' )-as_string,
+ 'https://127.1.2.4/pants',
+ 'Overriden base URI for HTTPS'
+);
+
Index: lib/Catalyst/Engine/CGI.pm
===
--- lib/Catalyst/Engine/CGI.pm (revision 8518)
+++ lib/Catalyst/Engine/CGI.pm (working copy)
@@ -160,11 +160,25 @@
$c-request-uri( bless \$uri, $uri_class );
# set the base URI
+
+my $base_uri;
+
+if (defined $c-config-{override_base_uri_secure} $c-request-secure) {
+ # Config gives us an override base for HTTPS. Use it directly.
+ $base_uri = $c-config-{override_base_uri_secure};
+} elsif (defined $c-config-{override_base_uri}) {
+ # Use an overriden base. If we're secure, but there's no separate HTTPS
+ # base URI, then just change the scheme on the standard one.
+ $base_uri = $c-config-{override_base_uri};
+ $base_uri =~ s,^([^:]+)://,${scheme}://,;
+} else {
+ # Use the server-provided (default) base path.
+ $base_uri = $scheme . '://' . $host . $base_path;
+}
+
# base must end in a slash
-$base_path .= '/' unless $base_path =~ m{/$};
+$base_uri .= '/' unless $base_uri =~ m{/$};
-my $base_uri = $scheme . '://' . $host . $base_path;
-
$c-request-base( bless \$base_uri, $uri_class );
}
___
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] Success stories please
On Sunday 05 October 2008 06:16:57 pm Mark Keating wrote: On 6 Oct 2008, at 00:01, J. Shirley wrote: Andy apparently just wanted to start a flamewar. This article is idiotic, the reasons more so. I'm disappointed in perlbuzz in general as it now holds the same amount of respect as getting my news from The National Inquirer. I'd encourage people to rather blog about finding the article to be in poor taste, then post their success stories. Commenting here or on that blog entry is going to be buried. ++ to this Thirdeded. The best cure for Andy is to ignore him. Andrew ___ 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] Multiple DB, single instance of Cat
On Thursday 11 September 2008 05:58:31 pm Nigel Stuckey wrote: Matt I stand corrected on DBIx! Yes, indeed I mean DBIx::Class. The code is in and works, but has a couple of issues. Firstly, it creates new classes and carries out a DB connect every time there is a request. Is there a way to make it more efficient by caching the classes and DB connects once there is a successful authentication? If you know what all of the possible organizations are, then write a model that instantiates all the DB connections (schemas, whatever) at 'new' time, then returns the appropriate one at ACCEPT_CONTEXT time. It's the here's one we prepared earlier approach. If that's not feasible, it should be obvious how to change it to doing nothing at startup, creating connections on demand, and caching them for the life of the process. Andrew ___ 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] Apache2::RequestIO::read problem
On Tuesday 29 July 2008 12:07:31 am Chris Dolan wrote: [error] Caught exception in engine Apache2::RequestIO::read: (104) Connection reset by peer at /home/foo/perl/lib/perl5/site_perl/5.8.8/ Catalyst/Engine/Apache.pm line 187 [Mon Jul 28 16:14:36 2008] [error] [client xxx.xxx.xxx.xxx] File does not exist: /home/foo/MyApp/root/student, referer: http://example.com/ student [snip] I'm seeing the problem with URLs other than just / student too, but all of these problems are infrequent and only after reset connections. I have not been able to reproduce the problem with my own web browser. I've seen more-or-less the same thing using C::P::Server::XMLRPC when it gets some data it really doesn't like. I don't understand it any more than you do but it seems harmless enough. As Bill Moseley said it seems that something is failing in a way that makes apache retry with the default-handler. Makes no sense to me, but it does fit hte bill. Andrew ___ 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] process stand alone css file with TT?
On Thursday 24 July 2008 03:11:26 pm Kyle Godbold wrote:
Is there any way to use Template Toolkit to render a stand alone
css page that can be linked in with link rel=stylesheet ? I've
tried rendering it through its own function and it will render the
css but the output isn't recognized and used by any page when its linked.
I'm not sure if its the header thats sent or the fact that it has no .css
extention in the filename when its downloaded.
sub style :Local {
my ( $self, $c ) = @_;
$c-stash-{template} = style.css; }
$c-res-content_type('text/css'); perhaps?
Andrew
___
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] Users hierarchy
On Friday 06 June 2008 10:46:53 pm Jonathan Rockway wrote: * On Fri, Jun 06 2008, [EMAIL PROTECTED] wrote: Gulp, that should have been 0 :) Actually, it should have been ! as in if(!$found ...). Perl has a variety of false values including 0, undef, and the empty string. Perl's built-in boolean operators return undef or 1 as false or true, but other libraries use other values ( and hey, it worked!, for example). Actually (0==1) is and defined, while we're picking nits. The point stands that if you want to test for truth you should simply test for truth. Andrew ___ 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] Catalyst website
Questions!
1) What is the preferred name for the Catalyst website? I thought that at one
point we were leaning toward sticking with catalyst.perl.org, but all the nav
links are for catalystframework.org. One way or another I think the site
should be clear on what it's named, and send a Moved Permanently redirect to
the preferred address when accessed using the nonpreferred address.
2) Will the new wiki go live[1] at its current toeat.com address or at
$answer{'Question 1'} . /wiki/?
3) Can we have a link to thebookerrata on the front page with the book link,
where newbies are likely to find it? Something to the tune of Having
trouble? Click here for important information on the Catalyst book. I will
happily submit patch to the website if this is not shot down.
4) Thoughts on improving the website in general? It's nice, but not very
filling, and I don't think it gets a lot of love. Again, I'd be happy to
help. Maybe this should wait for the new wiki though? I'm thinking that
either we would want to highlight some of the most important wiki articles
from the website, or else the wiki could end up being most of the website,
since it's powered by hierarchical fairy dust.
Thanks,
Andrew
[1] I think the new wiki is live in all but name anyway, and the old wiki is
getting stale, so I do hope that MojoMojo is production-quality soon!
___
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] DBIC error when starting dev server
On Monday 21 April 2008 09:08:37 pm Andrew wrote: I'm just starting with Catalyst (but experienced in MVC frameworks) and I got J. Rockway's book. I'm working through the 1st DB example (pages 27-30), where we use DBIC to connect to a simple database. http://catwiki.toeat.com/thebookerrata Specifically: On page 28, the \ characters are meant to be continuations of the command-line across newlines. The newlines were omitted, so you should also omit the \ characters. Andrew ___ 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] Http Status Chart
On Tuesday 11 March 2008 10:52:55 pm Evan Carroll wrote: On 3/11/08, Christopher H. Laco [EMAIL PROTECTED] wrote: This made it's way across reddit this morning... Nice chart. I always preferred digg with its posts of thought provoking cats and top ten teenage racks. With that said what is the diff between unauthorized and forbidden. The way I figure it, it should say unauthenticated except that that's not the word that the HTTP standard uses. Anyway, you get a 401 if the server doesn't know who you are, and it thinks that if you were the right person you might be able to perform that action. You get a 403 if you're not allowed to do that despite who you may or may not be. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Patch for Catalyst::View::Mason
On Sunday 09 March 2008 07:43:04 am Aristotle Pagaltzis wrote: I see your bid and raise this: autocmd BufRead */templates/tt/*set ft=tt2html autocmd BufRead */templates/mason/* set ft=mason Wheee. This is the slightly more effective version: au BufNewFile,BufRead */templates/tt/* setf tt2html au BufNewFile,BufRead */templates/mason/* setf mason Main difference being the BufNewFile handling (which you'll really miss if it's not there). setf is also more proper but it probably makes no difference at all in this case :) Andrew ___ 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] Environment Variables
On Wednesday 27 February 2008 04:39:22 pm Ryan Pack wrote:
Hello all. First time posting here. :-)
I'm trying to get at $ENV{HTTP_REFERER} from my catalyst app but it
doesn't seem to be there. In fact the only keys that exist in %ENV are
CATALYST_ENGINE and PERL5LIB. Are the others being wiped out somehow?
Not sure if this is normal Catalyst behavior. Thanks!
They're not being wiped out, they just don't exist to begin with. All those
envvars are part of CGI, and Catalyst is not CGI. Everything you need to know
about the incoming request should be in $c-request (alias $c-req).
Andrew
___
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] Documentation on DBIx Class
On Friday 18 January 2008 02:47:14 pm Mesdaq, Ali wrote: I have to just rant a bit about that. The most difficult thing about catalyst is trying to learn dbic. Except that's not a thing about catalyst. You don't need to use DBIC. It's a popular choice, sure, but if you think that something else would be eaiser, then go for it. Use Rose, invent your own wheel, or do what $WORK does and write a model that does nothing but stored-procedure calls (straight DBI and some glue). DBIC isn't required for using catalyst, it's just the standard choice for doing what DBIC does -- which most people find rather useful. Andrew ___ 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] utf8 / pg double encoding problem
On Saturday 05 January 2008 04:54:59 pm Daniel McBrearty wrote:
well I'm damned, I thought I had this stuff working squeaky clean. But
I was wrong. I actually had two bugs cancelling each other out -
usually.
[snip]
--' [debug] abçöeü
[debug] $VAR1 = ab\x{c3}\x{a7}\x{c3}\x{b6}e\x{c3}\x{bc};
[debug] it's UTF8!
Looks like the problem is here... the utf8 flag is on, indicating that $edit
is a string of characters, rather than bytes -- but the dumper output seems
to show that these characters correspond to UTF-8 encoded bytes, instead of
the actual characters of the data -- meaning that the bytes actually stored
in the string are along the lines of ab\x{c3}\x{83}\x{c2}\x{a7}... not
good. Somewhere, your data got the utf8 flag set by assumption instead of
by decoding. $edit = decode(UTF-8, $edit) should clear it up, although
finding the original problem is probably a better idea. :)
Andrew
___
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] More unicode problems (uri_for)
On Monday 24 December 2007 07:58:34 am Knut-Olav Hoven wrote:
I wasn't very clear on this, sorry.
Check my å is not inside the code, it comes from my po/mo-files (i18n).
It looks actually more like this:
$c-redirect(
$c-uri_for(
'/login',
{error_msg = $c-loc(Check my magic)}
);
);
po-file (utf8 encoded):
msgid Check my magic
msgstr Check my å
pofiles have a Content-Type header/declaration/whatever. Does your .po file
declare itself as
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
?
Andrew
___
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] retrieving multiple values from forms
On Monday 17 December 2007 03:01:53 pm Matt S Trout wrote:
On Sat, Dec 15, 2007 at 01:10:52PM -0600, Andrew Rodland wrote:
See the perldoc for Catalyst::Request -- the 'param' method comes in
handy here.
@values = $c-req-param('whatever');
No it doesn't.
That method is there for CGI.pm compatibility. Don't use it in new code.
It's also the only one that has a sensible semantic. Might be an unblessed
scalar or an arrayref is silly for something that's naturally a _list_. If
param wasn't there I would have to write a method that did the same thing,
and use that.
Andrew
___
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] Re: retrieving multiple values from forms
On Monday 17 December 2007 05:27:46 pm A. Pagaltzis wrote: The *sane* thing is neither. The sane thing is to have *TWO* methods, one that *always* returns a scalar, and one that *always* returns a list. (Or rather, an arrayref, because if it’s just a list, it is easy to improperly treat it like a scalar, whereas if it’s an arrayref it’s impossible to forget to unpack the array when you meant to do that.) Then you can say what you mean, you can say it *easily* either way, and the result is always completely determined by what the code says and not at all by what the data looks like. Sanity. Yeah, I can agree with this. I realized the same thing myself... after posting my original message of course. Teach me to wait a bit longer before hitting send in the future. Anyway yeah, what I really want is param_list or param_aref, without any of the actual CGI compat of param -- param just comes closer to my goal than params. Not sure what the ideal behavior for the only one version would be, but params is at least practical. If you see ARRAY(0xbadfad) where you expected useful data it's not that hard to trace back and see what you did wrong. Andrew ___ 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] Web hosting?
On Sunday 16 December 2007 06:50:41 am Matt Rosin wrote: I started this same thread a few months ago and many people were kind enough to reply. It seemed a decision between linode.com and slicehost.com. Slicehost sounds cool and very well may be cool, however it is newer, has a waiting list (not extremely long), and what got me was that they say no up front but then require up front just to get early on the list. Actually slicehost has cleared out their backlog, there's once again no wait. Minimum prepayment term is still 3 months and it doesn't look like they intend to change that, but if you cancel within a month (for example) they'll still refund you two. Larger prepayments get a discount, but that's probably not a big incentive if you're just trialing them :) Linode offers a bit more RAM and a higher bandwidth cap for the price, which is nice, while Slicehost gives you four virtual CPUs, more I/O allowance, and has a nifty backup system. Both have very responsible developers/admins. I've been running some things (including a couple Catalyst sites) on Slicehost now for over a year, and they've been good to me. No performance issues once I figured out how best to configure apache to save on memory. Linode certainly looks good too. I figure it's the kind of competition that benefits the customer. Andrew ___ 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] Catalyst Comprehensive Tutorials Needed
On Sunday 16 December 2007 01:40:57 am Tony Winslow wrote: Hi, all! I'm new to Catalyst. I'm eager to learn it. Yet I cannot find a systematic book or tutorial about it. Can anyone here help me find one or even write one for the world? Besides the book, of course, there's perldoc Catalyst::Manual::Tutorial :) Andrew ___ 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] A question on persistence with sessions or similar
On Tuesday 06 November 2007 09:40:01 pm Joe Landman wrote: Hi Folks: Here is what I want to do. I want to preserve values of stuff across the life of a session, without having to jump through hoops to do it. I want it to survive redirects in the app. It would be nice if it were just like stash. Really, it is very simple. And I thought I had it. $c-flash [...] Finally as an RFE for 5.8, it would be really, really nice if there was a $c-sessionstash that worked just like stash. Stash is great, things that work like stash are great. There is. It's called session. Flash works like session except that stuff disappears after the first time you read it -- thus the mysterious data dropouts. Andrew ___ 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/
