FAQ
I'm developing an app which uses IIS and FastCGI as its back end. Also,
we are expected by the client to use Windows integrated authentication
in the server -- this is an intranet app, so no login screen should be
expected.

Picking up the user id is fairly easy - it's set as the REMOTE_USER CGI
header by IIS authentication, and the engine puts it into the deprecated
$c->request->user. I was using this as the identity (bad, I know) and
got burned by the fact that we couldn't properly test multiple users
with Test::WWW::Mechanize::Catalyst.

I wanted to switch to Catalyst::Plugin::Authentication. This seemed a
little unusual when we aren't really doing any authentication, but
trying to read the one already performed, so I put together a
Catalyst::Authentication::Credential::Environment module, that simply
reads (the still deprecated) $c->request->user. I didn't really want to
do all the authentication with Catalyst::Plugin::Authentication, even
though is seems possible. And testing was now easy, we got per-user
sessions, and everything. Anyway, what I wrote as the main method was:

sub authenticate {
my ( $self, $c, $realm, $auth_info ) = @_;
$c->log->debug("Using environment authentication");
my $username = $c->request->user();
if ( defined( $username ) && ( $username ne '' )) {
my $user_obj = $realm->find_user( { username => $username }, $c );
if ( ref( $user_obj ) ) {
$user_obj->id( $username );
return $user_obj;
}
}
return;
}

Is there another simple but better way to achieve this? Ideally one
which avoids the deprecated $c->request->user. I'm only starting to use
Catalyst for authentication stuff.

All the best
Stuart
--
Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090603/0879bef0/attachment.htm

Search Discussions

  • Tomas Doran at Jun 3, 2009 at 5:41 pm

    Stuart Watt wrote:
    I'm developing an app which uses IIS and FastCGI as its back end. Also,
    we are expected by the client to use Windows integrated authentication
    in the server -- this is an intranet app, so no login screen should be
    expected. <snip>
    trying to read the one already performed, so I put together a
    Catalyst::Authentication::Credential::Environment module, that simply
    Doh, you appear to have duplicated a chunk of effort:

    http://dev.catalyst.perl.org/repos/Catalyst/branches/Catalyst-Plugin-Authentication/credential_remote/lib/Catalyst/Authentication/Credential/Remote.pm
    Is there another simple but better way to achieve this? Ideally one
    which avoids the deprecated $c->request->user. I'm only starting to use
    Catalyst for authentication stuff.
    Not at the moment / in a released state.

    The next Catalyst release will add $c->req->remote_user for this. There
    is currently a failing test (for a bug which has been in Catalyst
    forever) in trunk, and I'm hoping to get this fixed before we release
    5.80005.

    I'm also going to be reviewing / merging this branch of
    Catalyst::Plugin::Authentication soonish (which I'm seriously late on
    already)!

    So to answer your actual question, yes, what you're doing is the right
    thing to do, and will be present in 'officially released' software
    within the next couple of weeks max hopefully.

    If you fancy reviewing the code I linked about, and trying it out to see
    if it works for you, and commenting on anything you think needs work
    (including documentation!), then that would be a great help :)

    Cheers
    t0m
  • Stuart Watt at Jun 3, 2009 at 6:22 pm
    Many thanks, Tomas, just what I needed. Right now I'm still on 5.7 due
    to an immediate release, but next week I'll go to 5.8, and then I'll be
    happy to review and test a better solution. Credential::Remote looks
    like what I didn't find. When I started working with this authentication
    issue, I wouldn't even have understood Credential::Remote type code, but
    by Monday I'll be better placed and have time enough to give it a
    thorough test.

    All the best
    Stuart


    Tomas Doran wrote:
    Stuart Watt wrote:
    I'm developing an app which uses IIS and FastCGI as its back end.
    Also, we are expected by the client to use Windows integrated
    authentication in the server -- this is an intranet app, so no login
    screen should be expected. <snip>
    trying to read the one already performed, so I put together a
    Catalyst::Authentication::Credential::Environment module, that simply
    Doh, you appear to have duplicated a chunk of effort:

    http://dev.catalyst.perl.org/repos/Catalyst/branches/Catalyst-Plugin-Authentication/credential_remote/lib/Catalyst/Authentication/Credential/Remote.pm

    Is there another simple but better way to achieve this? Ideally one
    which avoids the deprecated $c->request->user. I'm only starting to
    use Catalyst for authentication stuff.
    Not at the moment / in a released state.

    The next Catalyst release will add $c->req->remote_user for this.
    There is currently a failing test (for a bug which has been in
    Catalyst forever) in trunk, and I'm hoping to get this fixed before we
    release 5.80005.

    I'm also going to be reviewing / merging this branch of
    Catalyst::Plugin::Authentication soonish (which I'm seriously late on
    already)!

    So to answer your actual question, yes, what you're doing is the right
    thing to do, and will be present in 'officially released' software
    within the next couple of weeks max hopefully.

    If you fancy reviewing the code I linked about, and trying it out to
    see if it works for you, and commenting on anything you think needs
    work (including documentation!), then that would be a great help :)

    Cheers
    t0m


    _______________________________________________
    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/

    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=8D20F27F14.90E6C
    --
    Stuart Watt
    ARM Product Developer
    Information Balance
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090603/2679a0bd/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 3, '09 at 2:07p
activeJun 3, '09 at 6:22p
posts3
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Stuart Watt: 2 posts Tomas Doran: 1 post

People

Translate

site design / logo © 2022 Grokbase