[Catalyst] 5.80005: $c->req->remote_user and apache: excluding actions from authentication

Tomas Doran bobtfish at bobtfish.net
Wed Jun 10 15:33:05 GMT 2009

Francesc Romà i Frigolé wrote:
> The applications I'm writing are expected to have a relatively small 
> number of users. From my experience so far the performance is quite good 
> on a shared hosting as long as I serve the static content from outside 
> Catalyst. Otherwise performance degrades significantly since each user 
> has to deal with a few static files that weight a few MB each.

Hmm, well, this strikes me as weird.

I have a 100Mb link (shared with other people) between myself and my 
live environment, and I thought I'd do a very quick test.

I tarred up 182Mb of crap.

Static apache: 11.19M/s

Put into a newly generated TestApp in root/static, running with the 
development server: 11.18M/s

So I think you're doing something severely non-optimum (or your shared 
hosting machines are totally swamped) if you're seeing significant 
performance degredation.

Do you see the same issues when testing locally, or just and your shared 
host, and what technique are you using to serve these static files?

> This approach works for me as long as the static content requires no 
> authentication or the whole site requires authentication. It just have 
> to edit a single .htaccess file.
> My concern is to keep the setup as simple as possible, and I find this 
> configuration very advantageous compared to dedicated/virtual hosting 
> since I don't have to take care of the servers (we are a small team with 
> more programming than systems administration experience)

YY, that's totally fair - unless you're trying to do reasonable scale 
(for example, I can do 3k concurrent sessions on a busy day), then it 
_just shouldn't matter_ to you.

> Now I'm facing a new situation which is that some parts of the Catalyst 
> application have to be public. Since it's not a very different situation 
> than what I had been doing so far I think is legitimate to expect to be 
> able to solve it with similar tools.

Yep, that's totally fair as long as you're prepared to give up a little 
flexibility :)

> For completeness sake I'll also say that there is a trivial solution 
> that avoids this trade off in flexibility: to set up a "guest" account. 
> But I don't like this solution because it would annoy guest users.

I'd say that the trivial solution is to use 
Catalyst::Authentication::Credential::HTTP, and 

As long as you present the same realm name for your HTTP authentication 
inside Catalyst as you do outside Catalyst, then users who have logged 
into other (non Catalyst powered) parts of your site will never notice.

You then get the flexibility to authenticate on arbitrary paths within 
your application, but you're using the same user credentials as other 
parts of your site doing apache auth, and everything is just transparent.


More information about the Catalyst mailing list