FAQ
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090609/25799fab/attachment.htm

Search Discussions

  • Tomas Doran at Jun 9, 2009 at 5:53 pm

    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
  • Francesc Romà i Frigolé at Jun 9, 2009 at 6:49 pm

    On Tue, Jun 9, 2009 at 7:53 PM, Tomas Doran 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 )



    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090609/e07faf69/attachment.htm
  • Tomas Doran at Jun 9, 2009 at 8:26 pm

    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
  • Kmx at Jun 10, 2009 at 5:23 am

    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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 8:40 am

    On Wed, Jun 10, 2009 at 7:23 AM, kmx wrote:

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

    thanks for the clarification kmx
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/3aa78f96/attachment.htm
  • Tomas Doran at Jun 10, 2009 at 9:13 am
    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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 8:40 am

    On Tue, Jun 9, 2009 at 10:26 PM, Tomas Doran 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/11f23c11/attachment.htm
  • Charlie Garrison at Jun 10, 2009 at 9:07 am
    Good evening,

    On 10/06/09 at 10:40 AM +0200, 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.
    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@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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 9:59 am

    On Wed, Jun 10, 2009 at 11:07 AM, Charlie Garrison 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?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/4989d105/attachment.htm
  • Charlie Garrison at Jun 10, 2009 at 10:47 am
    Good evening,

    On 10/06/09 at 11:59 AM +0200, Francesc Rom? i Frigol?
    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@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
  • Tomas Doran at Jun 10, 2009 at 9:17 am

    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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 10:06 am
    On Wed, Jun 10, 2009 at 11:17 AM, Tomas Doran 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/f85eab53/attachment.htm
  • Francesc Romà i Frigolé at Jun 10, 2009 at 11:06 am
    2009/6/10 Francesc Romà i Frigolé
    <francesc.roma+catalyst@gmail.com<francesc.roma%2Bcatalyst@gmail.com>
    >
    On Wed, Jun 10, 2009 at 11:17 AM, Tomas Doran 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 :(
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/5cfcfe1e/attachment.htm
  • Tomas Doran at Jun 10, 2009 at 11:55 am

    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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 2:50 pm
    On Wed, Jun 10, 2009 at 1:55 PM, Tomas Doran 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/4058ce01/attachment.htm
  • Tomas Doran at Jun 10, 2009 at 3:33 pm

    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
  • Francesc Romà i Frigolé at Jun 10, 2009 at 3:52 pm

    On Wed, Jun 10, 2009 at 5:33 PM, Tomas Doran 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090610/2f59164e/attachment.htm
  • Tomas Doran at Jun 10, 2009 at 4:13 pm

    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
  • Francesc Romà i Frigolé at Jun 19, 2009 at 3:12 pm

    On Wed, Jun 10, 2009 at 6:13 PM, Tomas Doran 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090619/83a02f9f/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 9, '09 at 5:45p
activeJun 19, '09 at 3:12p
posts20
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase