Skip Menu |

This queue is for tickets about the Maypole-Plugin-Session CPAN distribution.

Report information
The Basics
Id: 14562
Status: open
Priority: 0/
Queue: Maypole-Plugin-Session

People
Owner: Nobody in particular
Requestors: rmcclain [...] megapath.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.2
Fixed in: (no value)



Subject: Conflict with M:P:Authorization
I thought I filed a bug on this once before, but I can't find the email, so here we go again. There is apparently a conflict between M:P:Session and M:P:Authorization. They both try to do their own session handling and clobber each other. In my authenticate function, I call $r->get_session then $r->get_user. The call to $r->get_user segfaults. I tracked it to the validate call in _make_session in Apache::Session::Wrapper. It seems that UserSessionCookie calls login_user which then tries to create a session as a tied hash called %session, then calls $r->session(\%session). The problem is, the session sub used to be created by a mk_accessors call in UserSessionCookie, and now you are overriding it with completely different behavior. i.e. validate is expecting a list of arguments, not a hashref.
[guest - Mon Sep 12 21:50:06 2005]: Show quoted text
> I thought I filed a bug on this once before, but I can't find the > email, so here we go again. > > There is apparently a conflict between M:P:Session and > M:P:Authorization. They both try to do their own session handling > and clobber each other. In my authenticate function, I call $r-
> >get_session then $r->get_user. The call to $r->get_user
> segfaults. I tracked it to the validate call in _make_session in > Apache::Session::Wrapper. It seems that UserSessionCookie calls > login_user which then tries to create a session as a tied hash > called %session, then calls $r->session(\%session). The problem > is, the session sub used to be created by a mk_accessors call in > UserSessionCookie, and now you are overriding it with completely > different behavior. i.e. validate is expecting a list of > arguments, not a hashref. >
You mean M::P::Authentication::UserSessionCookie I guess? This is tricky. I guess I assumed if you have a M::P::Authentication::UserSessionCookie session, you wouldn't need a plain session. Of course lots of times you still do. How about calling login_user with no arguments? By the looks of it, that should give you a session but no user. So when authentication fails, just call login_user anyway. Let me know if that works, and I'll add a note to the M::P::Session docs. d.
From: rmcclain [...] megapath.net
[DAVEBAIRD - Tue Sep 13 06:11:43 2005]: Show quoted text
> [guest - Mon Sep 12 21:50:06 2005]: >
> > I thought I filed a bug on this once before, but I can't find the > > email, so here we go again. > > > > There is apparently a conflict between M:P:Session and > > M:P:Authorization. They both try to do their own session
> handling
> > and clobber each other. In my authenticate function, I call $r-
> > >get_session then $r->get_user. The call to $r->get_user
> > segfaults. I tracked it to the validate call in _make_session in > > Apache::Session::Wrapper. It seems that UserSessionCookie calls > > login_user which then tries to create a session as a tied hash > > called %session, then calls $r->session(\%session). The problem > > is, the session sub used to be created by a mk_accessors call in > > UserSessionCookie, and now you are overriding it with completely > > different behavior. i.e. validate is expecting a list of > > arguments, not a hashref. > >
> > You mean M::P::Authentication::UserSessionCookie I guess? This is > tricky. I guess I assumed if you have a > M::P::Authentication::UserSessionCookie session, you wouldn't need a > plain session. Of course lots of times you still do. > > How about calling login_user with no arguments? By the looks of it, > that > should give you a session but no user. So when authentication fails, > just call login_user anyway. Let me know if that works, and I'll add a > note to the M::P::Session docs. > > d. >
I've attached a fix. Should be BC, I think. The changes are all in sub session.
package Maypole::Plugin::Session; use 5.005; use warnings; use strict; use Maypole(); use Maypole::Config(); use Maypole::Constants(); use Apache::Session::Wrapper 0.24; Maypole::Config->mk_accessors('session'); Maypole->mk_accessors( 'apache_session_wrapper' ); =head1 NAME Maypole::Plugin::Session - simple sessions for Maypole =cut our $VERSION = 0.2; =head1 SYNOPSIS use Maypole::Application qw( Session ); 5B # Elsewhere in your app: my $session = $r->session; =head1 API CHANGES This version is a re-write using L<Apache::Session::Wrapper>. As such, the configuration parameters have changed - use L<Apache::Session::Wrapper> settings rather than L<Apache::Session> settings. See B<Configuration>. =head1 DESCRIPTION Provides C<session> and C<delete_session> methods for your Maypole request class. The session is implemented using L<Apache::Session::Wrapper>, and as such, a range of session store mechanisms are available. =head1 CONFIGURATION The B<Configuration> section of the L<Apache::Session::Wrapper> docs lists all the available parameters. These should be placed in the C<Maypole::Config::session> slot as a hashref. =over 4 =item setup If there are no settings in C<< Maypole::Config->session >>, then default settings for L<Apache::Session::File> are placed there. Also, cookies are turned on by default: $config->{session} = { class => 'File', directory => "/tmp/sessions", lock_directory => "/tmp/sessionlock", use_cookie => 1, cookie_name => 'maypole-plugin-session-cookie', }; You need to create these directories with appropriate permissions if you want to use these defaults. You can place custom settings there either before (preferably) or after (probably OK) calling C<< Maypole->setup >>, e.g. $r->config->session( { class => "Flex", store => 'DB_File', lock => 'Null', generate => 'MD5', serialize => 'Storable' } ); =cut sub setup { my $r = shift; # class name warn "Running " . __PACKAGE__ . " setup for $r" if $r->debug; # Apache::Session::Wrapper will use add() to set the cookie under CGI *Maypole::Headers::add = \&Maypole::Headers::push; my %defaults = ( class => 'File', directory => "/tmp/sessions", lock_directory => "/tmp/sessionlock", use_cookie => 1, cookie_name => 'maypole-plugin-session-cookie', ); my $cfg = $r->config->session || {}; if ( keys %$cfg ) { exists $cfg->{use_cookie} or $cfg->{use_cookie} = $defaults{use_cookie}; exists $cfg->{cookie_name} or $cfg->{cookie_name} = $defaults{cookie_name}; } else { %$cfg = %defaults; } $r->NEXT::DISTINCT::setup( @_ ); } =back =head1 METHODS =over 4 =item session Returns the session hashref. =item delete_session Deletes the session and cookie. =cut sub session { my $self = shift; if(ref($_[0])) { $self->apache_session_wrapper->{session} = $_[0]; return $self->apache_session_wrapper->session; } else { return $self->apache_session_wrapper->session( @_ ); } } sub delete_session { shift->apache_session_wrapper->delete_session( @_ ) } =back =head1 PRIVATE METHODS These are only necessary if you are writing custom C<authenticate> method(s). Otherwise, they are called for you. =over 4 =item authenticate This is called early in the Maypole request workflow, and is used as the hook to call C<get_session>. If you are writing your own C<authenticate> method(s), either in model classes or in the request classes, make sure your C<authenticate> method calls C<get_session>. =cut sub authenticate { my ( $r ) = @_; $r->get_session; return Maypole::Constants::OK; } =item get_session Retrieves the cookie from the browser and matches it up with a session in the store. You should call this method inside any custom C<authenticate> methods. =cut sub get_session { my ( $r ) = @_; # returning 1 silences an anonymous warning $r->can( 'ar' ) && $r->ar && $r->ar->register_cleanup( sub { $r->apache_session_wrapper->cleanup_session; 1 } ); $r->{apache_session_wrapper} = Apache::Session::Wrapper->new( header_object => $r, param_object => $r, %{ $r->config->session }, ); } =back =head1 SEE ALSO L<Apache::Session::Wrapper>. =head1 AUTHOR David Baird, C<< <cpan@riverside-cms.co.uk> >> =head1 BUGS Please report any bugs or feature requests to C<bug-maypole-plugin-session@rt.cpan.org>, or through the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Maypole-Plugin-Session>. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes. =head1 COPYRIGHT & LICENSE Copyright 2005 David Baird, All Rights Reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. =cut 1; # End of Maypole::Plugin::Session
[guest - Mon Sep 19 14:11:59 2005]: Show quoted text
> [DAVEBAIRD - Tue Sep 13 06:11:43 2005]: >
> > [guest - Mon Sep 12 21:50:06 2005]: > >
> > > I thought I filed a bug on this once before, but I can't find the > > > email, so here we go again. > > > > > > There is apparently a conflict between M:P:Session and > > > M:P:Authorization. They both try to do their own session
> > handling
> > > and clobber each other. In my authenticate function, I call
> $r-
> > > >get_session then $r->get_user. The call to $r->get_user
> > > segfaults. I tracked it to the validate call in _make_session
> in
> > > Apache::Session::Wrapper. It seems that UserSessionCookie
> calls
> > > login_user which then tries to create a session as a tied hash > > > called %session, then calls $r->session(\%session). The
> problem
> > > is, the session sub used to be created by a mk_accessors call
> in
> > > UserSessionCookie, and now you are overriding it with
> completely
> > > different behavior. i.e. validate is expecting a list of > > > arguments, not a hashref. > > >
> > > > You mean M::P::Authentication::UserSessionCookie I guess? This is > > tricky. I guess I assumed if you have a > > M::P::Authentication::UserSessionCookie session, you wouldn't need a > > plain session. Of course lots of times you still do. > > > > How about calling login_user with no arguments? By the looks of it, > > that > > should give you a session but no user. So when authentication fails, > > just call login_user anyway. Let me know if that works, and I'll add
> a
> > note to the M::P::Session docs. > > > > d. > >
> > > I've attached a fix. Should be BC, I think. The changes are all in > sub session. >
Thanks Ron. Can you summarize for me what it's doing? I don't use M-P-Authorization, so I don't understand the issue. Cheers, d.
From: rmcclain [...] megapath.net
[DAVEBAIRD - Tue Sep 20 04:29:49 2005]: Show quoted text
> [guest - Mon Sep 19 14:11:59 2005]: >
> > [DAVEBAIRD - Tue Sep 13 06:11:43 2005]: > >
> > > [guest - Mon Sep 12 21:50:06 2005]: > > >
> > > > I thought I filed a bug on this once before, but I can't find
> the
> > > > email, so here we go again. > > > > > > > > There is apparently a conflict between M:P:Session and > > > > M:P:Authorization. They both try to do their own session
> > > handling
> > > > and clobber each other. In my authenticate function, I call
> > $r-
> > > > >get_session then $r->get_user. The call to $r->get_user
> > > > segfaults. I tracked it to the validate call in
> _make_session
> > in
> > > > Apache::Session::Wrapper. It seems that UserSessionCookie
> > calls
> > > > login_user which then tries to create a session as a tied
> hash
> > > > called %session, then calls $r->session(\%session). The
> > problem
> > > > is, the session sub used to be created by a mk_accessors call
> > in
> > > > UserSessionCookie, and now you are overriding it with
> > completely
> > > > different behavior. i.e. validate is expecting a list of > > > > arguments, not a hashref. > > > >
> > > > > > You mean M::P::Authentication::UserSessionCookie I guess? This is > > > tricky. I guess I assumed if you have a > > > M::P::Authentication::UserSessionCookie session, you wouldn't need
> a
> > > plain session. Of course lots of times you still do. > > > > > > How about calling login_user with no arguments? By the looks of
> it,
> > > that > > > should give you a session but no user. So when authentication
> fails,
> > > just call login_user anyway. Let me know if that works, and I'll
> add
> > a
> > > note to the M::P::Session docs. > > > > > > d. > > >
> > > > > > I've attached a fix. Should be BC, I think. The changes are all in > > sub session. > >
> > Thanks Ron. Can you summarize for me what it's doing? I don't use > M-P-Authorization, so I don't understand the issue. > > Cheers, > > d. >
Well.. login_user in M:P:A:UserSessionCookie creates a tied hash to use as the session and calls $r->session(\%session), which is a method it creates using mk_accessors. Of course, you override that in your M:P:Session class, but it's not expecting to be called with an already built session. The hack I made is just a kludge to create an A:S:W class with the already created session. It actually seems to work just fine.. I can log in, log out, the get_authorized_methods and get_authorized_classes methods work fine, etc. I don't know what further implications there might be. I just know it works for me. It may not be the best way, as I don't think you're supposed to set $wrapper->{session} directly, but I didn't see a way in the A:S:W docs to create a wrapper around an existing session. At any rate, it should revert to the old behavior if the first argument isn't a hashref.
Any chance of this ever getting rolled in? I just set up a bunch of new installations and forgot about this.. Pulled my hair out a while going "WTF does apache keep segfaulting?" ;)