Tags:
create new tag
, view all tags

SessionPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on SessionPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on SessionPlugin

I've replaced Sessionplugin with the implementation of SmartSessionPlugin - soon I'll delete that topic and merge the Devs.

-- MartinCleaver - Wednesday 29 Sep 2004

Is the old topic content archived? How about SessionPluginDevArchive, also with old attachments moved there?

-- PeterThoeny - 30 Sep 2004

Whilst SessionPlugin was more of an example than final code, I was never sure that SmartSessionPlugin was fully correct. Some aspects of it looked like misunderstandings.

-- JohnTalintyre - 30 Sep 2004

Just installed SessionPlugin on a Cairo/Apache 2.0.52/Perl 5.8.3/speedyCGI/Fedora C2 with 2.6.7 stock kernel. I followed the install section in SessionPlugin step by step. It did not mention the install script but I decided to follow it anyway.

I have it working now (I think) but I ran into the following problems and annoyances.

  • As always I have to manually change access rights and owner of all the files. Maybe the install script should prompt you for the Apache username so it can do the chown and chmod for you. This is general for all plugins actually.
  • The install script prompted me once for pressing ENTER and then quietly ended like it had finished its business. But I could not see any changes made afterwards.
  • The plugin did not work. The issue was that the CPAN module CPAN:CGI::Session was not installed. In the documentation this library is mentioned as used technology but it is not obvious that you have an installation task to do. This is an easy fix. Edit the Install section to include this little detail. I have edited the SessionPlugin#Plugin_Installation_Instructions section. Naturally it is still missing in the .txt doc in the zip file. I will not try to mess with that. I added the exact commands to run. I personally always end up Googling for them. It is nice to include in the install steps and cost one line of text.
  • Should the install script have tried to install the CGI::Session module? Or at least warned me about it.

I have one question. I currently have TWiki.cfg parameter $doRememberRemoteUser = "1". What is the advice? Should this be set to 0 when using SessionPlugin? Or does it become a don't care? If it is critical weather it is 1 or 0 it should be added to the steps in the SessionPlugin#Plugin_Installation_Instructions section.

-- KennethLavrsen - 30 Sep 2004

The SessionPlugin still does not seems to be fully compatible with mod_perl/SpeedyCGI.

At least it fails on my installation when running SpeedyCGI. Here are the failure modes.

All tests are done on an Apache 2.0.52 on Linux. The tests done.

  1. Open a TWiki page with a freshly opened browser.
  2. Navigate around and notice that the WebLeftBar shows the logon at the bottom. No user left bar
  3. a. Either click the logon link on the left menu bar.
  4. b. Or edit a page and cancel out.
  5. In both cases this should cause an authentication and from then on you should be known so that any further editing does not require authentication and the left manu bar should include your user bar and not show the login link.

Only CGI - SpeedyCGI is deactivated Plugin works
view,edit,save etc runs under SpeedyCGI.

viewauth runs under normal CGI
When you start by pressing login the plugin works and you can edit a page after without authentication.
If you start by editing (getting authenticated) the left menu bar still only shows the logon. When you press logon you get authenticated and then it seems to work. In practical this is too confusing for the user.
All bin perl scripts run under SpeedyCGI The plugin does not work well at all. The left menu bar keeps on going back to the initial logon screen.

So there is still some static global variable left to be eliminated before this plugin is fully mod_perl/SpeedyCGI compatible. I am not sure if the issue is in viewauth or the Plugin itself so maybe I should also file this as a regular bug in codev.

-- KennethLavrsen - 02 Oct 2004

It's been a while since I've been involved with SessionPlugin's development, so I'm a bit out of the loop on what changes have been made to the original SmartSessionPlugin I submitted more than a year ago, but Martin asked me to take a look at some of the things on this page, and I have a couple of responses (namely to the doRememberRemoteUser question and to the question of SpeedyCGI/mod_perl). Hopefully the most recent SessionPlugin changes don't make these points moot.

  • (doRememberRemoteUser) With regard to $doRememberRemoteUser, in most cases I would recommend turning it off. For one, I'm not sure that the two authentication engines will necessarily mesh together in all cases. Ideally, in the case where a browser does not support session cookies, doRememoberRemoteUser will do its best to keep track of that person by IP. However, if someone also from that IP (say they are both behind the same firewall) logs in (and perhaps even supports cookies so is handled by SmartSessionPlugin regardless of what doRememberRemoteUser wants), then there may be a security problem there. In general, $doRememberRemoteUser is just a flawed and deprecated way of remembering users who were logged in. I think it's perfectly reasonable to require users to turn on per-session cookies for authentication purposes.

  • (SpeedyCGI/mod_perl) Now, I have not seen CairoRelease, but I believe the problems described are the same problems we had the previous release. It's not a problem with SessionPlugin, it is a problem with where authentication falls in TWiki in general. From what I remember, the nice thing about CairoRelease is that a new procedure was going to be added that would run far ahead of all of the initialization. This was needed because in order for TWiki to get initialized, it needed to know who was logged in. When SpeedyCGI/mod_perl is used, TWiki never re-initializes itself and the user sticks permanently. TWiki itself needs to become less dependent upon NEEDING to know who is logged on.

  • (aside: authentication in TWiki) An aside: I don't know if much work has been done on this yet, but if it hasn't, I still believe that one of TWiki's biggest downsides right now is that for the most part it is dependent upon some other mechanism for authentication. It has been designed with some ROUGH support for passing information back and forth with different authentication systems, but this support is really designed for the advanced user. When no other authentication system is available (so for most users in general), it falls back on the web server authentication that provides no good way to logout. This all seems a bit silly. Serious work needs to be done on building a good authentication engine for TWiki that allows for flexible logins and the possibility to logout. Web server authentication was never meant to be used to this extent.

  • (conclusion: authentication is a messy issue with TWiki) Because authentication was never given the attention I think it should be given (see the aside), poor design decisions were made about how authentication should be thought about within TWiki. This led to things like $doRememberRemoteUser and the need to know the user logged in FIRST above all other information. People need to rethink TWiki's authentication mechanisms, and this needs to be done at a CORE LEVEL. Per-session cookies do not necessarily need to become part of the core code, but the existence of things like per-session cookies need to be kept IN MIND when making such design decisions. Without major changes to TWiki CORE code, there will be no major advances in convenient authentication mechanisms for TWiki.

-- TedPavlic - 03 Oct 2004

I should be a little more fair about the SpeedyCGI/mod_perl. With SpeedyCGI/mod_perl turned on, doRememberRemoteUser works fine, so the MECHANISM for doing what needs to be done is within TWiki SOMEWHERE, it just requires some sort of patch to let SessionPlugin active the same "switch persistent user" features as doRememberRemoteUser.

-- TedPavlic - 03 Oct 2004

I have noticed that the first time you authenticate with a browser, Apache logs this error.

[Thu Oct 07 08:41:22 2004] [error] [client 192.168.1.9] [Thu Oct  7 08:41:22 2004]
  edit: Use of uninitialized value in string ne at /usr/local/apache2/twiki/lib/TWiki/Plugins/SessionPlugin.pm line 674.,
  referer: http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

I am not running mod_perl or SpeedyCGI at the moment. Maybe this error is related to the problem I reported above. At least it is not an error message that signals health

-- KennethLavrsen - 07 Oct 2004

I have a couple of implementation problems with SessionPlugin.

1. I have 2 TWiki websites on the same box (for 2 organizations). I did something bad recently--possibly removed some other Plugin that SessionPlugin wanted. Now, if I browse the 2 different webs, I sometimes see these errors at the very bottom of the rendered page:

[Thu Oct 21 14:53:05 2004] view: (in cleanup) could not flush: Couldn't store 9d471efd008a831809faeafd23904f84 into /tmp/cgisess_9d471efd008a831809faeafd23904f84: Permission denied at /homeb/pauljohn/public_html/cgi-bin/twiki/view line 0

2. If I do not log in, a session file is still created in /tmp, and today I noticed there were 6000 of them in the /tmp dir. Maybe it is overflowing /tmp!?? Could that cause error 1? Is there a configuration option to have no Session whatsoever for TWikiGuest users, and then only pop one up for people who go through the log in process?

-- PaulJohnson - 21 Oct 2004

It occurs to me that SessionPlugin could easily be decoupled from HttpAuthentication. Doing so would mean we could allow users to login using any of their details (LoginName/WikiName/Email address) and to be able to log out.

Has anyone done any coding around this? IIRC there was something on TWikiIRC a while back.

-- MartinCleaver - 09 Nov 2004

I'm running into the same error as KennethLavrsen is above - namely: Use of uninitialized value in string ne at ../lib/TWiki/Plugins/SessionPlugin.pm line 674.

I deleted my cookies - no whenever I attempt to login I get that error. Not being a serious perl hack - I don't really see anything wrong with the line, can someone with more experience take a look?

-- PaulPetterson - 25 Nov 2004

I actually found a fix for the error message a few days ago and came by this page to share it.

The line that creates the error in SessionPlugin is line 674 which looks like this:

$session->clear() if( defined($session) && defined($session->param) && 
                      defined($query) && defined( $query->remote_user() ) &&
                      defined($authUserSessionVar) && 
                      "" ne $query->remote_user() && 
                      "" ne $session->param( $authUserSessionVar ) &&
                      $query->remote_user() ne $session->param( $authUserSessionVar ) );
Simply change it to this.
$session->clear() if( defined($session) && defined($session->param) && 
                      defined($query) && defined( $query->remote_user() ) &&
                      defined($authUserSessionVar) && defined( $session->param( $authUserSessionVar ) ) &&
                      "" ne $query->remote_user() && 
                      "" ne $session->param( $authUserSessionVar ) &&
                      $query->remote_user() ne $session->param( $authUserSessionVar ) );

Note that what I add is && defined( $session->param( $authUserSessionVar ) )

-- KennethLavrsen - 25 Nov 2004

Kenneth - please feel free to just republish the zip on the SessionPlugin with your changes.

-- MartinCleaver - 26 Nov 2004

On the subject of the many /tmp/cgisess_* files, one way to deal with those is to install the CPAN:CGI::Session::ExpireSessions module from CPAN and run something like the following every few hours as a cron job:

#!/usr/bin/perl
use strict;
use warnings;
use CGI::Session::ExpireSessions;
CGI::Session::ExpireSessions
    -> new(temp_dir => '/tmp', verbose => 1, delta => 12*60*60)
    -> expire_file_sessions();

-- IanYoung - 26 Nov 2004

I have updated the SessionPlugin with my little fix (2.991). I uploaded a fix twice because first I forgot that I had to also update the SessionPlugin.txt topic file in the package. I notice that there may also be a version in some CVS. But CVS is voodoo to me so if a CVS version must be updated one of you more experienced will have to do that. I hope I did everything right.

-- KennethLavrsen - 28 Nov 2004

After reading the plugin page, I come away with this understanding: it is possible to viewauth only bin/logon and still retain author tracking on edits? E.g. I could simplify my .htaccess to:

<Files logon>
require valid user
</Files>
<Files *>
allow from all
</Files> 
is this correct?

-- MattWilkie - 22 Dec 2004

I was having a similar problem [to KennethLavrsen]] with SessionPlugin and mod_perl. After a lot of debugging, I discovered that the problem seems to be with the use of CGI::Session. In particular, that module assumes that the program will exit in order to flush out the session information, since under mod_perl the instances don't exit, session updates aren't reliably flushed, and I would get intermittent success for logins. The attached file sessionplugin.patch fixes the problem, in particular, at line 699 of version 2.9 of the plugin, right after the call to $session->param( $authUserSessionVar, $authUser ); I added a call to $session->flush(). I moved the if() test around both calls. This made the session plugin start working reliably for me, whereas before it was somewhat random as to whether or not it would work.

-- EricAnderson - 28 Mar 2005

Adding session handling to TWiki is essential. IP address matching is worthless.

  • On the big Internet any user browsing from a on office will be behind a NAT router and probably also a proxy, making him one of maybe 100000 users with the same IP address.
  • In an Intranet envionment I see so often meetings using a meeting room computer for recording minutes, and actions. And we ended up being "logged in" as the previous authenticated user. That is no good.

I represent two user groups because I manage two very different TWIkis. One is a public TWiki for an open source project: http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome. The other is an Intranet TWiki at Motorola Copenhagen. In both cases SessionPlugin - or rather its functionality - is a "make or break" feature. Without both Wikis would have been something else than TWiki.

  • On the public TWiki SessionPlugin enables my users to login once and keep their personal left bar and being able to edit many pages without having to authenticate all the time. Before SessionPlugin several users had the problem with taking over someone elses identity. Quite many of my users seem to take a break at the office and relax by participating in open source projects.
  • At Motorola the doRememberUser had the "meeting room" problem again and again. TWiki with the Actiontracker-plugin is such a nice meeting application. But we have a more severe issue which almost forced me to give up TWiki.
    • It is a MUST in a modern company that you do not have 10-30 different passwords to remember. All webbased applications must be authenticated via the corporate LDAP server. The problem in global corporations is that an LDAP server is always loaded and the server is at a remote physical location. Our LDAP server takes 2-7 seconds to authenticate - on average 3-4. Most of our TWIki webs have Set DISALLOWTOPICVIEW TWikiGuest (and DISALLOW any editing/remaming naturally) and no guest account login. So navigating to any page takes 2-7 seconds. You cannot live with that. SessionPlugin saves the day!!. You simply setup Apache to only authenticate viewauth while leaving edit, view etc etc unauthenticated.
      The result: You only authenticate ONCE and SessionPlugin handles the rest giving both read and edit access at an amazing speed.

So please make sure SessionPlugin is part of Dakar. Either as a fully supported Plugin. Or better as part of the Dakar package. As a user/administrator it is not essential whether the functionality is built-in to the core software or a plugin like TablePlugin is today. But please - whetever you do. Implement session handling so that LDAP authenticated users only have to LDAP authenticate ONCE per session.

Last comment. The session files in the temp directory is a problem with an easy solution. I run this simple script from cron once per day. Add this or something similar to the package and it is OK.

#!/usr/bin/perl -wT

use strict;
my $sessionDir = "/tmp";
my $expireThreshold = 86400 * 5; #keep session files for 5 days

chdir $sessionDir;

opendir INDIR, '.';
while (defined (my $fname = readdir INDIR))
{
    next if $fname !~ /^cgisess_.*$/;
    my ($size, $mtime) = (stat $fname)[7, 9];
    $fname =~ /(.*)/;
    $fname = $1;
    if ($size == 0)
    {
   unlink $fname;
   next;
    }
    if (time - $mtime > $expireThreshold)
    {
   unlink $fname;
   next;
    }
}
closedir INDIR;

-- KennethLavrsen - 06 Apr 2005

I'd like to see the SessionPlugin NOT create a new session until someone has either explicitly LOGGED IN or EDITED a page.

This would cut down alot on disk churn in /tmp.

Also, our twiki install (biostat.mc.vanderbilt.edu) gets hammered by search indexers quite a bit, and I'm not sure of this, but if thoses indexers don't accept cookies, then a new session would be created for every single page access on the site........

-- JeffreyHorner - 06 Apr 2005

In order to make the page w3c compliant you need to s/"&"/"&amp;"/ on lib/SessionPlugin.pm: I'm testing it at thetabase.net and its working fine sofar. (hope this helps)

-- TravisBarker - 22 Apr 2005

line 876: my $logon ... "warning" needs to be quoted for w3c compliance

-- TravisBarker - 22 Apr 2005

actually no, it needs escaped and quoted, sorry smile \"warning\"

-- TravisBarker - 22 Apr 2005

travis, please provide a patch diff file diff -U or cvs diff

-- WillNorris - 23 Apr 2005

I am using the SessionPlugin with ApplicationAuthenticationAddOn Plugin. Many time Users session were logged out. Noticed the comments from users in SessionPluginDev. So I modified the SessionPlugin.pm Script.

I have attached the script with this topic. To use it, replace the old file with the attached SessionPlugin.pm. Modify the DSN field to the driver of your choice at line number 752 and 765. I have tested the plugin for driver:File and dirver:DB_File drivers on Cairo Release.

Also modify = {Directory=>'/tmp'}= to the directory of your choice, at lines 753 and 766.

Its always better to do the maintenance of /tmp directory if you are using the driver:File as your driver. The script provided by KennethLavrsen can be used to do maintenance, thanks KennethLavrsen for providing the script.

If you want to use the driver::DB_File as your driver, the following script can be useful.


#!/usr/bin/perl

use strict;
use warnings;
use DB_File ;

my $expireThreshold = 86400 * 5; #keep session  5 days (access time)
my $database_file_name = "cgisess.db";

my (%h, $k, $v) ;

tie %h, "DB_File", $database_file_name, O_RDWR|O_CREAT, 0666, $DB_HASH
        or die "could not open the session database: $!\n";


    while (($k, $v) = each %h)
    { my  $D;
      eval $v;
      my $atime = $D->{'_SESSION_ATIME'};
      if (time -$atime> $expireThreshold) {  delete $h{$k}; }
    }

untie %h ;

-- SopanShewale - 05 Jun 2005

Hi, I've got a question about the 'transparency' of this plugin. See SessionPluginNotTransparent. I hope someone can give me a clue!

-- JosMaccabiani - 10 Jul 2005

Hi, i have installed twiki and i wont to add new users but in the registration form does not have the password field and re-enter password... What can i do to resolve this question!Can anybody help?Thanks...

-- JoaquimFerreira - 01 Aug 2005

Joaquim - I suspect you missed step 3 in TWiki.TWikiInstallationGuide#Enabling_Authentication_of_Users where you replace the content of TWikiRegistration with that of TWikiRegistrationPub.

-- LynnwoodBrown - 01 Aug 2005

Hi,my authentication is now working.Before installing SessionPlugin when i edit a topic, login/password are required and in my revision says: Revision r1.1 - 05 Aug 2005 - 12:05 - IspAdmin. After installing SessionPlugin, no login is required and my revision is..TwikiGuest. I don't know why..can anybody give me some tips?Thanks..

-- JoaquimFerreira - 08 Aug 2005

Joaquim - have you carefully followed all the installation steps outlined in SessionsPlugin, including confirming that you have the CGI::Session moduled installed?

-- LynnwoodBrown - 08 Aug 2005

Yes, i've followed all the steps...the SessionPlugin is defined but not installed, in InstalledPlugins. Doesn't return any errors...and still doesn't stay installed..Have no idea..It's needed to add/modify SessionPlugin.pm??Thanks for the help.

-- JoaquimFerreira - 08 Aug 2005

Hi,my SessionPlugin is installed but %SESSION_IS_AUTHENTICATED% is allways 0 and my TWikiGuest is always TwikiGuest. I think that's because it cant creat the session files in /tmp (i supose)..I'm tryng to solve this..but ran out of ideas.The directory /tmp have correct permissions and owner..could this be any problem with CGI???Any help would be great!Thanks

-- JoaquimFerreira - 09 Aug 2005

I need some help. I have the plugin installed. I have a problem calling the variables %SESSION_IF_NOT_AUTHENTICATED% . It works if i have the conditional loop all on one line (that is no return or spaces), but when I add a return or space it doesn't work. Also adding in another TWikiVariable to the mix inside of a Session variable does not work either. Is it supposed to? What might be wrong? Any help if you could email me jeffpipas@jeffpipasPLEASENOSPAM.com. Thanks

-- JeffPipas - 22 Aug 2005

Following on from EricAnderson's patch, I've gone and tracked all the places in which session state is changed but not flushed. This is less efficient, but more reliable:

--- SessionPlugin.pm.orig       2005-09-07 19:03:04.000000000 +0100
+++ SessionPlugin.pm    2005-09-07 19:13:37.000000000 +0100
@@ -522,6 +522,7 @@
     #
     if( ( $_[0] ne $authUserSessionVar ) && defined( $session->param( $_[0], $_[1] ) ) )
     {
+        $session->flush();
         return 1;
     }

@@ -549,6 +550,7 @@
     if( ( $_[0] ne $authUserSessionVar ) && defined( $session->param( $_[0] ) ) )
     {
         $session->clear( [ $_[0] ] );
+        $session->flush();

         return 1;
     }
@@ -671,12 +673,16 @@
         #
         # All these defined's are here to quiet down the highly overrated perl -w.
         #
-        $session->clear() if( defined($session) && defined($session->param) &&
-                              defined($query) && defined( $query->remote_user() ) &&
-                              defined($authUserSessionVar) && defined( $session->param( $authUserSessionVar ) ) &&
-                              "" ne $query->remote_user() &&
-                              "" ne $session->param( $authUserSessionVar ) &&
-                              $query->remote_user() ne $session->param( $authUserSessionVar ) );
+        if( defined($session) && defined($session->param) &&
+            defined($query) && defined( $query->remote_user() ) &&
+            defined($authUserSessionVar) && defined( $session->param( $authUserSessionVar ) ) &&
+            "" ne $query->remote_user() &&
+            "" ne $session->param( $authUserSessionVar ) &&
+            $query->remote_user() ne $session->param( $authUserSessionVar ) )
+        {
+            $session->clear();
+            $session->flush();
+        }

         # See whether the user was logged in (first webserver, then session, then default)
         $authUser = $query->remote_user() ||
@@ -688,6 +694,7 @@
 #        if ( $ENV{'REDIRECT_STATUS'} eq '401' ) {
 #          TWiki::Func::writeDebug( "- TWiki::Plugins::${pluginName}::_init_authuser Invalidating session due to 401 status" ) if ($debug);
 #            $session->clear();
+#             $session->flush();
 #            $sessionIsAuthenticated = 0;
 #            return 1;
 #        }
@@ -695,7 +702,10 @@
         # Save the user's information again if they do not appear to be a guest
         if( TWiki::Func::getDefaultUserName() ne $authUser )
         {
-            $session->param( $authUserSessionVar, $authUser ) if defined( $authUserSessionVar );
+            if (defined $authUserSessionVar) {
+              $session->param( $authUserSessionVar, $authUser );
+              $session->flush();
+            }
         }

         return 1;

-- SimonFarnsworth - 08 Sep 2005

Simon, is this a superset of Eric's patch, or is that still required? I'd like to make sure the Dakar code (which builds sessions into the kernel) is consistent.

-- CrawfordCurrie - 08 Sep 2005

It's a superset of Eric's patch.

Eric changed the block at line 695 to call $session->flush after $session->param() was used to set the authenticated user in the session variables. I've gone further, and called $session->flush() after every set of session variables, and after every clear; there is still no flush on get.

If I were aiming to do this cleanly and efficiently, I'd work out how to get a callback after output is complete (at the point when any print will cause an error), and call $session->flush then, rather than scatter $session->flush throughout the code.

-- SimonFarnsworth - 08 Sep 2005

I made some changes to the Plugin topic, prompted by users recreating a SESSIONLOGONURL topic over and over again. I removed confusing links to itself; escaped some links; changed some links to Interwiki links; added GNU and Appraisal to table.

Please feel free to take the changes (raw) back into the next release.

-- PeterThoeny - 08 Sep 2005

I was just tripped up by the session-didn't-flush-at-exit problem as well, and wonder whether it might not be better to just insure that $session is undefined when the page request completes. For cgi-script sites, it should be sufficient to add an END { $session->DESTROY if defined $session } to SessionPlugin.pm. For mod_perl sites, it'd also be necessary to add a cleanup handler. Is this worthwhile? Is it general enough that there's a plan for a TWiki Plugin function that would allow plugins to register a cleanup callback?

-- CharlesBailey - 11 Sep 2005

Simon; do you mean any print to STDOUT or just any print? Flushing the session at the end of writing to STDOUT is trivial.

-- CrawfordCurrie - 12 Sep 2005

The session needs to be flushed after all sets and clears have completed; this means after the session ID is set, after sticky skin handling, and after all %SET_SESSION_VARIABLE% and %CLEAR_SESSION_VARIABLE% elements are parsed and handled. Under CGI, this is simple; CGI::Session flushes on exit, cleaning up for you. Under mod_perl, CGI::Session needs to be kicked into flushing after all sets and clears for a page view.

-- SimonFarnsworth - 13 Sep 2005

Unfortunately, CGI::Session won't reliably flush on exit, since it depends on order of global destruction; it fails for me using perl 5.9.2. An END block takes care of the problem, and it looks like it'll work under mod_perl's Apache::Registry (mod_perl 1) or Modperl::Registry (mod_perl 2) handlers as well. (I haven't tested this, since I don't have a handy site running mod_perl.) Since I doubt there's much call to use another handler, I'd suggest simply adding

--- lib/TWiki/Plugins/SessionPlugin.pm~ Sun Nov 28 09:46:30 2004
+++ lib/TWiki/Plugins/SessionPlugin.pm  Wed Sep 14 16:42:20 2005
@@ -902,4 +902,10 @@
 
 # =========================
 
+# Insure that the session data is safely flushed before we exit.
+# We explicitly call DESTROY in case someone else has accidentally
+# held onto a reference to this global var; absent that concern, a
+# simple undef would do.
+END { $session->DESTROY if defined $session; }
+
1;
to the current code.

-- CharlesBailey - 14 Sep 2005

I need to develop a log-out and log-in strategy. I'm going to have a go at this today personally, and the approach I'm going to try is the following:

  • add deleteSession() function that calls $session->delete();
  • write a logon script that
    • takes username, password as form parameters
    • looks up .htpasswd, if match, create session
  • modify templates to reject user if not authenticated (no session ID)

Just to echo the comment by CharlesBailey..

So, I'm using ApplicationAuthenticationAddOn, and relatively happy with it. Unfortunately I've had to edit the SessionPlugin.pm file to add $session->flush() every time a change is made to the session (such as clearing, or setting parameters). Why? Because I'm running under mod_perl and sessions don't get flushed because the module doesn't get destroyed after serving a page.

My request to developers is to edit SessionPlugin and add deliberate session flushing code? Many thanks.

-- PeterPayne - 25 Oct 2005

DakarRelease has extensively reworked session handling. I'd advise you spend your time looking at that first.

-- MartinCleaver - 25 Oct 2005

Hi,

I've installed TWiki with the NATSKINPLUGIN and I've installed Session Plugin however I'm receiving an error I cannot for the life of me figure out...

I click logon. Then type in my username and password and click submit. I get the following:

Software error: Can't call method "param" on an undefined value at /twiki/lib/TWiki/Plugins/NatSkinPlugin/Auth.pm line 188.

Please can someone help me out?

-- StevenGreen - 13 Jan 2006

This is Line 188 of my Auth.pm file:

$session->param($AuthUserSessionVar, $theUser);

-- StevenGreen - 13 Jan 2006

Steven: Are you running Dakar or Cairo?

  • If Dakar then you don't need this plugin - remove it - the functionality is in the Dakar core.
  • If Cairo the report this in the Support web where it will get more attention and you can more fully describe your system and configuraiton, all vital information to help us debug your problem.

-- AntonAylward - 13 Jan 2006

After applying the most recent version of the SessionPlugin (v 2.992) I found I was unable to logon and the following was in apache's error_log :

Permission denied: exec of '../twiki/bin/logon' failed

The answer was to chmod the logon script and make it executable by the web server.

-- KeithHelfrich - 06 Feb 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch SessionPlugin.headers.patch r1 manage 1.7 K 2002-04-20 - 15:43 UnknownUser Fix to work with new plugin API
Perl source code filepm SessionPlugin.pm r1 manage 37.5 K 2005-06-05 - 07:32 UnknownUser To use this, copy this on old file.
Unknown file formatpre-release-plugin-rewrite SessionPlugin.pm.pre-release-plugin-rewrite r1 manage 12.2 K 2003-07-16 - 11:49 UnknownUser Solves viewauth problem; removes need4logon script
Unknown file formatEXT cleansessions r1 manage 2.6 K 2002-09-11 - 17:58 UnknownUser Clean out old/null/obsolete session files
Unknown file formatgz sessionId-bug-patch.diff.gz r1 manage 0.6 K 2002-09-16 - 09:46 UnknownUser Ostrich algorithim applied to lack of sessionId.
Unknown file formatpatch sessionplugin.patch r1 manage 0.8 K 2005-03-28 - 00:56 UnknownUser Patch to make session plugin work better with mod_perl
Edit | Attach | Watch | Print version | History: r64 < r63 < r62 < r61 < r60 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r64 - 2007-02-06 - KeithHelfrich
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.