Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

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

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


francesc.roma+catalyst at gmail

Jun 9, 2009, 10:45 AM

Post #1 of 20 (1325 views)
Permalink
5.80005: $c->req->remote_user and apache: excluding actions from authentication

Hello,

This is more of an apache question than a Catalyst one, but I'd appreciate
some help.

I'm trying the new feature $c->req->remote_user introduced in 5.80005. I'd
like to know if it is possible to tell apache, in a .htaccess file, to not
ask authentication for a certain set of URIs (for example matching /public/)

I'm on a shared account in asmallorange.com ( apache 1.3.41). I'm using
fastcgi.

Regards,
Francesc


bobtfish at bobtfish

Jun 9, 2009, 10:53 AM

Post #2 of 20 (1293 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

Francesc Romà i Frigolé wrote:
> This is more of an apache question than a Catalyst one, but I'd
> appreciate some help.
>
> I'm trying the new feature $c->req->remote_user introduced in 5.80005.
> I'd like to know if it is possible to tell apache, in a .htaccess file,
> to not ask authentication for a certain set of URIs (for example
> matching /public/)

Yes, it is.

<Location /public>
Satisfy Any
Allow from All
</Location>

should do what you want.

Also, if you haven't seen it yet:
http://search.cpan.org/~bobtfish/Catalyst-Plugin-Authentication-0.10012/lib/Catalyst/Authentication/Credential/Remote.pm

may be helpful to you later on.

Cheers
t0m



_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 9, 2009, 11:49 AM

Post #3 of 20 (1287 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Tue, Jun 9, 2009 at 7:53 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

> Francesc Romà i Frigolé wrote:
>
>> This is more of an apache question than a Catalyst one, but I'd appreciate
>> some help.
>>
>> I'm trying the new feature $c->req->remote_user introduced in 5.80005. I'd
>> like to know if it is possible to tell apache, in a .htaccess file, to not
>> ask authentication for a certain set of URIs (for example matching /public/)
>>
>
> Yes, it is.
>
> <Location /public>
> Satisfy Any
> Allow from All
> </Location>
>
> should do what you want.
>


Thanks Tomas, but I get the error: .htaccess: <Location not allowed here

This is because <Location> is not an "htaccess directive". See
http://httpd.apache.org/docs/1.3/mod/core.html#location

I also tried with <FilesMatch> which it is allowed, but it doesn't seem to
work (which makes sense because I'm not actually matching any file but a
catalyst action )



>
> Also, if you haven't seen it yet:
>
> http://search.cpan.org/~bobtfish/Catalyst-Plugin-Authentication-0.10012/lib/Catalyst/Authentication/Credential/Remote.pm<http://search.cpan.org/%7Ebobtfish/Catalyst-Plugin-Authentication-0.10012/lib/Catalyst/Authentication/Credential/Remote.pm>
>


It looks very interesting. From your explanation

# in your Controller/Root.pm you can implement "auto-login" in this way
sub begin : Private {
my ( $self, $c ) = @_;

unless ($c->user_exists) {
# authenticate() for this module does not need any user info
# as the username is taken from $c->req->remote_user and
# password is not needed

unless ($c->authenticate( {} )) {
# return 403 forbidden or kick out the user in other way
};
}
}


it seems that it should be possible to tell apache that authentication is
optional, but I don't know how to do that. How can I make apache ask for a
username/password but not return a 401 Authorization Required error?

Thanks,
Francesc


bobtfish at bobtfish

Jun 9, 2009, 1:26 PM

Post #4 of 20 (1284 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On 9 Jun 2009, at 19:49, Francesc Romà i Frigolé wrote:
> I also tried with <FilesMatch> which it is allowed, but it doesn't
> seem to work (which makes sense because I'm not actually matching
> any file but a catalyst action )
>

Ah, if you've got rules sending stuff to Catalyst, then stuff will be
sent to Catalyst to deal with, normal rules are unlikely to apply.

Inside Catalyst you can trivially continue the same authentication
you were using outside of Catalyst however, see
Catalyst::Authentication::Credential::HTTP and
Catalyst::Authentication::Store::Htpasswd..

> It looks very interesting. From your explanation
>

Nono, not my explanation, none of the code linked was written by me,
I just released it last.

Specifically, kmx++ for that credential.

> # in your Controller/Root.pm you can implement "auto-login" in
> this way
> sub begin : Private {
> my ( $self, $c ) = @_;
>
>
> unless ($c->user_exists) {
> # authenticate() for this module does not need any user
> info
> # as the username is taken from $c->req->remote_user and
> # password is not needed
>
>
> unless ($c->authenticate( {} )) {
> # return 403 forbidden or kick out the user in other way
> };
> }
> }

Erm, no - $c->authenticate will _always_ succeed if you're using
Credential::Remote, as the web server above you will have always
authenticated you already..

It's for use in situations where you don't want Catalyst to care
about auth, but you _do_ want to load details about the already
logged in user (from the DBIx::Class auth store for example).

> it seems that it should be possible to tell apache that
> authentication is optional, but I don't know how to do that. How
> can I make apache ask for a username/password but not return a 401
> Authorization Required error?

No.

This is implicit in the HTTP auth protocol.

You can limit it to authenticating only for some HTTP methods (which
is how publicly readable subversion works), but from the server side,
you either say 'needs auth, give the user a password prompt', or you
don't..

This (and the ugly password box) is why most 'internet' websites
implement auth with a login form - you can be a lot more flexible
about the level of user-authenticity you require at each stage...

Cheers
t0m


_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


kmx at volny

Jun 9, 2009, 10:23 PM

Post #5 of 20 (1271 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

> Erm, no - $c->authenticate will _always_ succeed if you're using
> Credential::Remote, as the web server above you will have always
> authenticated you already..
In fact there are some situations where Credential::Remote's
authenticate(..) can fail:
- REMOTE_USER is not set or is empty (= no authentication was performed
on Apache level)
- REMOTE_USER did not pass allow_regexp / deny_regexp check
- and of course if your Catalyst::Authentication::Store does not know
the REMOTE_USER (this is not gonna happen if you are using
C::A::Store::Null)

You can look into source code - it is not so complicated.

--
kmx

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 10, 2009, 1:40 AM

Post #6 of 20 (1271 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Tue, Jun 9, 2009 at 10:26 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

> This (and the ugly password box) is why most 'internet' websites implement
> auth with a login form - you can be a lot more flexible about the level of
> user-authenticity you require at each stage...



Thanks for the explanation. There are two reasons why I'm considering HTTP
auth despite it's lack of flexibility. I'd be happy to hear about
altrenatives.

1) static performance: serving static files directly from apache is much
faster than through catalyst. I find it specially noticeable with big files
like large pictures and pdfs. Some of the files should not be public. If I
do authentication in catalyst I can't serve them directly from apache.

2) dynamic/AJAX laziness: pages that use XMLHttpRequest stop working when
authentication expires. Unless I manually detect the condition and allow the
user to re-authenticate. Using HTTP auth should let the browser take care of
this.

Regards,
Francesc


francesc.roma+catalyst at gmail

Jun 10, 2009, 1:40 AM

Post #7 of 20 (1273 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 7:23 AM, kmx <kmx[at]volny.cz> wrote:

> In fact there are some situations where Credential::Remote's
> authenticate(..) can fail:
>


thanks for the clarification kmx


garrison at zeta

Jun 10, 2009, 2:07 AM

Post #8 of 20 (1271 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

Good evening,

On 10/06/09 at 10:40 AM +0200, Francesc Romà i Frigolé
<francesc.roma+catalyst[at]gmail.com> wrote:

>1) static performance: serving static files directly from apache is much
>faster than through catalyst. I find it specially noticeable with big files
>like large pictures and pdfs. Some of the files should not be public. If I
>do authentication in catalyst I can't serve them directly from apache.

You might be looking for mod_auth_tkt. There is also x-sendfile
but I don't have experience with that one.

<http://www.openfusion.com.au/labs/mod_auth_tkt/>


Charlie

--
Charlie Garrison <garrison[at]zeta.org.au>
PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Jun 10, 2009, 2:13 AM

Post #9 of 20 (1273 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On 10 Jun 2009, at 06:23, kmx wrote:

>
>> Erm, no - $c->authenticate will _always_ succeed if you're using
>> Credential::Remote, as the web server above you will have always
>> authenticated you already..
> In fact there are some situations where Credential::Remote's
> authenticate(..) can fail:
>

One stands corrected, that's what I get for describing how code works
without glancing at the docs again - +1 fail to me.

Cheers
t0m


_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Jun 10, 2009, 2:17 AM

Post #10 of 20 (1272 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On 10 Jun 2009, at 09:40, Francesc Romà i Frigolé wrote:
> 1) static performance: serving static files directly from apache is
> much faster than through catalyst. I find it specially noticeable
> with big files like large pictures and pdfs. Some of the files
> should not be public. If I do authentication in catalyst I can't
> serve them directly from apache.

Nod so.

Look at mod_sendfile, which implements lighty's X-SendFile

Personally, I use nginx and its X-Accel-Redirect as I'm proxying
files from other web servers (MogileFS), rather
than serving them from local disk. But either way - you can do your
Authentication, Authorization and Auditing in Catalyst, then delegate
back to your web server for actually shoveling the bytes down the wire.

> 2) dynamic/AJAX laziness: pages that use XMLHttpRequest stop
> working when authentication expires. Unless I manually detect the
> condition and allow the user to re-authenticate. Using HTTP auth
> should let the browser take care of this.

Erm, the reason that this will never fail with HTTP auth is that http
auth never expires (well, it always lasts one browser session), and
the browser sends the auth credentials with each request.

You can get the same effect by setting the correct options on your
session cookie.

Cheers
t0m


_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 10, 2009, 2:59 AM

Post #11 of 20 (1270 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 11:07 AM, Charlie Garrison <garrison[at]zeta.org.au>wrote:

>
>
> You might be looking for mod_auth_tkt. There is also x-sendfile but I don't
> have experience with that one.
>



mod_auth_tkt looks interesting but I wonder if it would interrupt the normal
flow of the application in case the session expires.

from http://www.openfusion.com.au/labs/mod_auth_tkt/


Requests without a valid ticket are redirected to a configurable URL which
> is expected to validate the user and generate a ticket for them. This
> package includes a Perl module and working CGI scripts for generating the
> cookies, as well as contributed classes for PHP and Python environments.
>


For example, imagine it expires while a user is filling out a lengthly form
and a drop down menu triggers an XMLHttpRequest. Would she be redirected to
the authentication form and loose all the information already typed?


francesc.roma+catalyst at gmail

Jun 10, 2009, 3:06 AM

Post #12 of 20 (1268 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 11:17 AM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

>
> On 10 Jun 2009, at 09:40, Francesc Romà i Frigolé wrote:
>
>> 1) static performance: serving static files directly from apache is much
>> faster than through catalyst. I find it specially noticeable with big files
>> like large pictures and pdfs. Some of the files should not be public. If I
>> do authentication in catalyst I can't serve them directly from apache.
>>
>
> Nod so.
>
> Look at mod_sendfile, which implements lighty's X-SendFile
>

Google thinks you meant mod_xsendfile: http://tn123.ath.cx/mod_xsendfile/

It looks very interesting but I wonder if my shared host provider
(asmallorange) would agree to install it.



2) dynamic/AJAX laziness: pages that use XMLHttpRequest stop working when
> authentication expires. Unless I manually detect the condition and allow the
> user to re-authenticate. Using HTTP auth should let the browser take care of
> this.
>

Erm, the reason that this will never fail with HTTP auth is that http auth
> never expires (well, it always lasts one browser session), and the browser
> sends the auth credentials with each request.
>

Good point !!!!



>
> You can get the same effect by setting the correct options on your session
> cookie.
>


I'll look into that then. Thanks


garrison at zeta

Jun 10, 2009, 3:47 AM

Post #13 of 20 (1274 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

Good evening,

On 10/06/09 at 11:59 AM +0200, Francesc Romà i Frigolé
<francesc.roma+catalyst[at]gmail.com> wrote:

>mod_auth_tkt looks interesting but I wonder if it would interrupt the normal
>flow of the application in case the session expires.

Expiration time is configurable. You can also have the session
timeout renewed on each request (send new auth_tkt cookie) if
that suits your needs.

So just set a long expiration and update cookie more often than
expiry duration.


Charlie

--
Charlie Garrison <garrison[at]zeta.org.au>
PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 10, 2009, 4:06 AM

Post #14 of 20 (1270 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

2009/6/10 Francesc Romà i Frigolé
<francesc.roma+catalyst[at]gmail.com<francesc.roma%2Bcatalyst[at]gmail.com>
>

>
> On Wed, Jun 10, 2009 at 11:17 AM, Tomas Doran <bobtfish[at]bobtfish.net>wrote:
>
>>
>> Look at mod_sendfile, which implements lighty's X-SendFile
>>
>
> Google thinks you meant mod_xsendfile: http://tn123.ath.cx/mod_xsendfile/
>
> It looks very interesting but I wonder if my shared host provider
> (asmallorange) would agree to install it.
>


I've noticed that
Catalyst::Plugin::XSendFile<http://search.cpan.org/perldoc?Catalyst::Plugin::XSendFile>has
been crossed out as a recommended plugin. I wonder why:
http://dev.catalystframework.org/wiki/recommended_plugins.jsrpc/diff/169/21

Aso, I just realized that mod_xsendfile is for apache 2 but my provider uses
apache 1 :(


bobtfish at bobtfish

Jun 10, 2009, 4:55 AM

Post #15 of 20 (1273 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

Francesc Romà i Frigolé wrote:
> It looks very interesting but I wonder if my shared host provider
> (asmallorange) would agree to install it.

You're worrying about the efficiency of pushing bytes around, but you're
using shared hosting.

Surely this is premature optimisation?

Cheers
t0m

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 10, 2009, 7:50 AM

Post #16 of 20 (1269 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 1:55 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

You're worrying about the efficiency of pushing bytes around, but you're
> using shared hosting.
>
> Surely this is premature optimisation?
>


t0m,

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.

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)

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.

I'm very grateful to you and kmx and Charlie for your help. Thanks to you
(and a bit of research and experimentation on my own) I've learned that for
achieving this goal I will have to sacrifice some flexibility: I should
design my applications in a way that there is only two paths that lead to
secure content (one that goes through catalyst and one that is static). In
this way I can solve the problem with a simple directory structure and two
.htaccess files. The layout of the public files/actions is not restricted. I
can't have paths to actions that behave differently depending on whether or
not the user has logged in.

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.

Through this discussion I've learned valuable knowledge which will help me
make design and planning decisions.

Thanks again to all for your replies,
Francesc


bobtfish at bobtfish

Jun 10, 2009, 8:33 AM

Post #17 of 20 (1267 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

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
Catalyst::Authentication::Store::Htpasswd.

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.

Cheers
t0m


_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 10, 2009, 8:52 AM

Post #18 of 20 (1267 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 5:33 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

> 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?
>


Thanks for taking the time for testing this. I did my tests some months ago
with smaller files (1-5 MB) and I don't remember the exact results now, but
I clearly remember that it made a very significant difference. Both
perceptually and numerically. Since the deployment documentation recommends
not serving static files with catalyst I assumed it was normal.

I won't have time today, but I tomorrow I'll do more tests and report the
results

cheers
Francesc


bobtfish at bobtfish

Jun 10, 2009, 9:13 AM

Post #19 of 20 (1267 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

Francesc Romà i Frigolé wrote:
> I did my tests some months
> ago with smaller files (1-5 MB) and I don't remember the exact results
> now, but I clearly remember that it made a very significant difference.

Hmm, well, with smaller files you have tcp slow start, and other effects
that can cloud your results - you specifically mentioned throughput, so
I tested with a fairly large file to eliminate those effects :)

> Both perceptually and numerically. Since the deployment documentation
> recommends not serving static files with catalyst I assumed it was normal.

I'd still recommend serving your CSS/JS/icons directly through apache,
it is more efficient.

But for things like document downloads with access control etc, then
just using:

http://search.cpan.org/~flora/Catalyst-Plugin-Static-Simple-0.21/lib/Catalyst/Plugin/Static/Simple.pm#serve_static_file_$file_path

very much works 'well enough' until you have lots (10s) of concurrent
downloads.

Cheers
t0m

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


francesc.roma+catalyst at gmail

Jun 19, 2009, 8:12 AM

Post #20 of 20 (1012 views)
Permalink
Re: 5.80005: $c->req->remote_user and apache: excluding actions from authentication [In reply to]

On Wed, Jun 10, 2009 at 6:13 PM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

>
> Both perceptually and numerically. Since the deployment documentation
>> recommends not serving static files with catalyst I assumed it was normal.
>>
>
> I'd still recommend serving your CSS/JS/icons directly through apache, it
> is more efficient.
>
> But for things like document downloads with access control etc, then just
> using:
>
>
> http://search.cpan.org/~flora/Catalyst-Plugin-Static-Simple-0.21/lib/Catalyst/Plugin/Static/Simple.pm#serve_static_file_$file_path<http://search.cpan.org/%7Eflora/Catalyst-Plugin-Static-Simple-0.21/lib/Catalyst/Plugin/Static/Simple.pm#serve_static_file_$file_path>
>
> very much works 'well enough' until you have lots (10s) of concurrent
> downloads.
>


t0m,

Sorry for taking so long to reply. I didn't have time to do some tests until
yesterday.

You were right and I was wrong: I couldn't find any measurable difference
between serving files directly with apache or with
Catalyst::Plugin::Static::Simple on the conditions we had discussed. I've
been repeating the test during last 24h to see if there where any
differences depending on server conditions, but results have remained
consistent. I tested with relatively small files (around 1MB) because the
impact of tcp slow start should be more noticeable. I'm not concerned about
smaller files since I don't have any privacy issues for things like CSS and
icons.

Therefore I don't have any reason anymore to use HTTP auth, which will make
my setup much simpler :)

I don't have any notes on how I tested last time, so I don't know what went
wrong. I'll write what I did this time for future reference. It's a really
simple test

1) created application TestDownload with catalyst 5.8005

2) set logging for Catalyst::Plugin::Static::Simple in lib/TestDownload.pm,
to be able to verify whether files are being served by catalyst or apache.
Added line __PACKAGE__->config->{static}->{logging} = 1;

3) put a few images and an html file that displays the images in
root/static. I called the html file test.htm (not html) so that
C:P:Static::Simple doesn't ignore it.

4) ln -s root/static root/public

5) Edit apache's .htaccess to send to catalyst the contents of the static
directory but not the public directory

AddHandler fastcgi-script .pl
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} /static/
RewriteRule ^(.*)$ script/testdownload_fastcgi.pl/$1 [QSA,L]

6) with Firefox 3, open the uri static/test.htm and public/test.htm. Check
in the logs that I get the traces from C:P:Static:Simple for the files under
static/ but not for the files under public/ .

Measured network statistics with firebug.

Results: On a 6MB cable connection across the Atlantic, for downloading the
html and 5 images of about 5MB total, it takes about 11s +/- 2s. The results
are distributed randomly in this range, they are highly correlated for both
scenarios. Sometimes the files served by catalyst arrive a few 100 ms faster
than the ones served by apache, sometimes is the other way around. The 5
images are downloaded in parallel, which is relevant for my usage scenario.

Sometimes the application is not running, and it needs to be restarted,
which takes about 5s extra, but that's not relevant for this test.

I hope this can be useful for somebody else.

Thanks again to all who replied.

Francesc

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.