Feedback on SmartSessionPlugin

Discussion here has much to do with SessionPlugin / SessionPluginDev as well.

Simple step-by-step instructions how to use this plugin are at SmartSessionCookbook

SmartSessionPlugin should work with SpeedyCGI now . . .

As of version 2.122, which was just uploaded today, which operates the initialization routines that cause all the trouble in different places, I believe I've made enough of a HACK to make SmartSessionPlugin work with SpeedyCGI and still work with non-SpeedyCGI users.

I'd appreciate feedback on whether or not it actually works. I don't have SpeedyCGI installed on my machine, so I'm just assuming that this fixes the problem based on descriptions given above.

See the SmartSessionPlugin topic for V2.122.

-- TedPavlic - 03 Sep 2003

Regarding bin/logon, you might be able to retire it and move the login functionality to a special topic that does the logon. That way you do not need to clutter the bin directory. See UrlParamWithNewlineArg for a how to.

If you do not intend to ship SmartSessionCookbook with the Plugin it is better to refer to it as TWiki:Plugins/SmartSessionCookbook in the Plugins topic.

BTW, this topic is getting long. Better to move older stuff to a SmartSessionPluginDevArchive topic.

-- PeterThoeny - 04 Sep 2003

I don't quite understand how the login functionality could move to a special topic that does the logon. The magic of bin/logon is that it is protected the same was scripts like bin/edit are protected. Its implementation simply redirects the user to the bin/view version of the web and topic it was passed. For example, linking to:

https://twiki.org/cgi-bin/logon/Plugins/SmartSessionPluginDev

Would cause Apache to require authentication. Once it had it, it would redirect to:

https://twiki.org/cgi-bin/view/Plugins/SmartSessionPluginDev

Understand that bin/logon is not the beast that retrieves username information and sets the authentication user session variable. bin/logon just forces the other authentication mechanism to kick in. Once SmartSessionPlugin sees that the user has authenticated, it grabs that authentication information and stamps it on the session.

So really bin/logon might as well be called bin/redirect. This was in the original implementation of SessionPlugin. It allows a user to logon without having to do something less intuitive like editing a page and cancelling, which would also log the user on.

Am I missing something?

-- TedPavlic - 04 Sep 2003

I was having trouble with the previous release of SmartSessionPlugin... got the logon prompt but didn't authenticate. (.htpasswd works to read, change, write). the new SessionPlugin.pm causes an internal server error, crashing my twiki when placed in twiki/lib/TWiki/Plugins/

-- BenjaminFleischer - 06 Sep 2003

Benjamin, I cannot replicate the problems you are having. I installed SmartSessionPlugin on a fairly bare bones TWiki site and it worked fine out of the box.

Make sure:

• bin/logon is in your .htaccess file as prescribed by the installation instructions
• CGI::Session and all of its dependencies are installed (like Digest::MD5 and Storable)
• That all of the permissions are set correctly on the TWiki files
  • SessionPlugin.pm needs to be readable by the webserver
  • SessionPlugin.txt needs to be readable (and writable) by the webserver
  • bin/logon needs to be executable by the webserver

And if you are still having the troubles, if you're getting an internal server error, please look at your web server's error log. This is often located in somewhere like /var/log/httpd/error_log. This should give you a better description of what's going on.

Another thing you can try is to manually run your mailnotify script. Just run bin/mailnotify from a command prompt. It may cause notifications to be sent out earlier than usual, but it will do no harm. If TWiki is dying while it is being loaded, it should also affect mailnotify.

Please let me know what the error in your error log is.

-- TedPavlic - 06 Sep 2003

Oh, I see. I did not realize that the authenticated login script does nothing else then a redirect to the actual topic. I assumed that it does some additional logic, hence my suggestion.

The TWiki docs already recomments to create a copy or a symbolic link from view to viewauth, and to put viewauth under auhentication. Does that give you the logon functionality you need?

-- PeterThoeny - 06 Sep 2003

Peter, there are a number of problems with the typical viewauth method that have been discussed at ImproveViewAuthentication and BetterThandoRememberRemoteUser. One of the major problems involves the lack of transparency. For at least a moment, the user sees "viewauth" in the URL. One of the major reasons SmartSessionPlugin was introduced with authentication features was so that users would be able to show their authenticated name on all pages without having to use any of the more intrusive solutions to that problem.

Yes, any page that forces an authentication will get caught by SmartSessionPlugin. Editing a page, for example, serves the same purpose. bin/logon provides a more elegant solution to this problem forcing a logon, returning the user to the same view page, and preventing the TWiki administrator from using a clunky viewauth solution. bin/viewauth is primarily used to keep the user in AuthenticatedMode for longer and longer time. Its major flaw (without sessions) is that links in AuthenticatedMode are to NonAuthenticatedMode pages. BetterThandoRememberRemoteUser fixes this problem in an equally intrusive manner but allows the user to stay in AuthenticatedMode for longer.

SmartSessionPlugin attempts to provide a plugin-centric (i.e., requires no patch) transparent alterantive to all of these, removing the need for the distinction between AuthenticatedMode and NonAuthenticatedMode pages. bin/logon assists when using Apache's "Basic Authentication" thus bridging the gap between the world of Authenticated vs. NonAuthenticated mode to the world of no such modes. It does this by being an AuthenticatedMode script that immediately refreshes to a NonAuthenticatedMode script.

So I'd rather not drop bin/logon as it takes away from some of the nicer features of SmartSessionPlugin.

-- TedPavlic - 06 Sep 2003

I'm running Apache 2 on Windows 2K using Activestate perl 2.8 (most recent ver ATM). I see a couple of problems, which seem to be easily fixable:

• On windows there is no /tmp dir. Therefore I think we should go with your suggestion to create a .session dir under the data dir, and add that in the documentation (I only found this by going through the code...)
• More tricky was that the code kept creating more and more sessions for me. The $query was correct, but it seems that the session data is not stored on disk until you kill the session. However, your line which attempts to create a new session was not picking up the in-memory version at all (at least on windows). I have changed the code so that is sets the $session to undef first, then tries to create a new object.
• I log in immediately if I use the edit key, but clicking the "LOGON" link in the top of tiger skin needs to be done twice... Perhaps I missed some documentation on customising tiger skin though?

Updated sub is below:

    sub _init_authuser
    {
    ...
        #
+        $session = undef; #Make sure the old stuff is flushed

!        $session = new CGI::Session("driver:File", $query, {Directory=>TWiki::Func::getDataDir . '/.session'});
!        #$session = new CGI::Session("driver:File", $query, {Directory=>'/tmp'});

    ...

        # See whether the user was logged in (first webserver, then session, then default)
        $authUser = $query->remote_user() ||
                    $session->param( $authUserSessionVar ) ||
                    TWiki::Func::getDefaultUserName(); 

-        $sessionIsAuthenticated = defined( $session->param( $authUserSessionVar ) ) ? 1 : 0;

        # 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 );
+      $session->flush(); # Force early disk write
        }

+        $sessionIsAuthenticated = defined( $session->param( $authUserSessionVar ) ) ? 1 : 0;

-- EdWildgoose - 09 Sep 2003

I'm running Apache 2.0 with mod_perl 1.99_05-dev on Redhat 8.0. I was having the same problems that EdWildgoose was having where it was creating lots of sessions for me. I was able to fix my problems by making the changes that EdWildgoose proposed (minus the /tmp fix). In addition, I wasn't able to get the StickySkin feature to work either. But following in the same vein as above, I was able to make a fix. Updated sub is below:

sub setSessionValueHandler
{
    ...
    #
    if( ( $_[0] ne $authUserSessionVar ) && defined( $session->param( $_[0], $_[1] ) ) )
    {
+        $session->flush();
        return 1;
    }

    return undef;

}

...

sub clearSessionValueHandler
{
    ...
    #
    if( ( $_[0] ne $authUserSessionVar ) && defined( $session->param( $_[0] ) ) )
    {
        $session->clear( [ $_[0] ] );
+        $session->flush();

        return 1;
    }

    return undef;

}

-- BillNapier - 24 Sep 2003

Any reason logon doesn't use the below which is in all the other cgi-bin's? The current implementation uses relative paths which break on my server.

BEGIN { unshift @INC, '.'; require 'setlib.cfg' }

I'm using this with KoalaSkin and one thing looks a bit strange - can you please change the Logon>> built into SESSIONLOGON so that the variable just says Logon and the >> bit is part of one of your templates? Thanks.

-- MartinCleaver - 06 Nov 2003

Hi Ted.

I've not modified SmartSessionPlugin but I am seeing some really weird things. I can reproduce them on your site too.

If I try to log in and get the password wrong, the SESSION_IF_AUTHENTICATED does the wrong thing.

i.e. If I go to http://www.osufirst.org/twiki/bin/view/OSUFIRST/WebHome and repeatedly type FooBar as the user id, leaving the password blank, authentication, as it should, fails. I then go back to http://www.osufirst.org/twiki/bin/view/OSUFIRST/WebHome and where it used to say "<---Login--->" it now says "User FooBar", which is blatently wrong because I have never registered.

Another problem I am experiencing, which is perhaps related (I can't tell), is that instead of getting the user topic written I get "No permission to read topic NewUserTemplate" hardcoded in the user topic. As I am sure you can tell this is very disturbing to newly registered people.

A fix for the first and any indication on the second would be very much appreciated.

-- MartinCleaver - 11 Nov 2003

KoalaSkin webs-navigation-bar does not preserve the session-id unless cookies are enabled.

The installation process of the KoalaSkin involves running bin/koalaskin-generate. This is an off-line tool used to generate the run-time-templates from a set of generic templates. Amongst others, this generation process adds the necessary code for the inter-webs-navigation-bar (top of screen). I guess you could call this a sort of semi-static approach

I could go ahead and manually edit these templates after generation. I.e. adding ?%SESSIONVAR%=%SESSIONID% for each of the inter-web links. However, this implies a cookie enabled browser will see the session id as well. My approach seems to be both ugly and a lot of work. Suggestions – on both items?

-- HansPype - 19 Nov 2003

I have found a similar problem to Martin's problem. The problem seems to be that the session is not cleared when the user cancels, but the remote_user is still set. This is because the ErrorDocument for 401 errors is set to a TWiki page which itself will use the session code and gets told the remote_user from the CGI query. Some code needs to be changed to not add the remote_user to the session if the user failed to Authenticate. Maybe the easiest way to do this is to exclude the session code from the autherror oops page? Or add code to that page to clear the session?

-- KimCovil - 11 Dec 2003

Looking further at the installation we have here (Tru64, Apache, perl 5.8) I have found Apache sets a REDIRECT_STATUS environment variable to 401 when the user failed to authenticate. I have added the following code into the _init_authuser sub of SessionPlugin.pm:

--- lib/TWiki/Plugins/SessionPlugin.pm~ 2004-04-12 07:48:30.000000000 -0500
+++ lib/TWiki/Plugins/SessionPlugin.pm  2004-05-16 11:05:06.000000000 -0500
@@ -683,6 +683,13 @@

         $sessionIsAuthenticated = defined( $session->param( $authUserSessionVar ) ) ? 1 : 0;

+        if ( $ENV{'REDIRECT_STATUS'} eq '401' ) {
+           TWiki::Func::writeDebug( "- TWiki::Plugins::${pluginName}::_init_authuser Invalidating session due to 401 status" ) if ($debug);
+             $session->clear();
+             $sessionIsAuthenticated = 0;
+             return 1;
+        }
+
         # Save the user's information again if they do not appear to be a guest
         if( TWiki::Func::getDefaultUserName() ne $authUser )
         {

This seems to have fixed the problem here, though I am not sure how cross platform the REDIRECT_STATUS variable is.

Hope that helps.

• I've changed this into a patch; I hope its in the right place but it looks okay to me. -- MartinCleaver - 16 May 2004

I'm just drawing attention to a help request I posted at SmartSessionPluginProblems which appears similar to the recent note posted in SmartSessionCookbook by LarsUffmann on 05 Jan 2004. Any further suggestions or ideas about trouble-shooting this plugin would be appreciated because I'm very interested in utilizing some of it's features.

-- LynnwoodBrown - 07 Jan 2004

Is anyone using an HTML form login rather than that annoying popup box to authenticate?

• This could be done with a combination of the authentication method shown in http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/CookBook.pm#MEMBERS_AREA and the integration method used in SiteMinderPlugin - MRJC

-- SamAbrams - 11 Feb 2004

Add this to SessionPlugin.pm to make it initialise under Cairo

sub earlyInitPlugin
{
    _init_authuser();
}

-- MartinCleaver - 12 Apr 2004

And this patch instructs people that if they can't see a topic it might be because they are not logged in.

--- templates/oopsaccessview.tmpl       2004-05-05 19:06:24.000000000 -0500
+++ templates/oopsaccessview.tmpl-      2004-05-05 19:01:45.000000000 -0500
@@ -3,10 +3,7 @@
 %TMPL:DEF{"webaction"}% *Attention* %TMPL:END%
 %TMPL:DEF{"heading"}%View Access Denied%TMPL:END%
 %TMPL:DEF{"message"}%
-
-%SESSION_IF_AUTHENTICATED% Sorry, %WIKIUSERNAME%, you do not have permission to view topic <nop>%WEB%.<nop>%TOPIC%.  %SESSION_ELSE% This page is protected - perhaps you need to log in? [[TWiki.TWikiRegistration][Register]] | &lt;&lt;%SESSIONLOGON% %SESSION_ENDIF%
-
-
+You do not have permission to view topic <nop>%WEB%.<nop>%TOPIC%.

 Contact
 <a href="mailto:%WIKIWEBMASTER%?subject=View&#32;Access&#32;Denied&#32;for&#32;'%WEB%.%TOPIC%'">%WIKIWEBMASTER%</a>

-- MartinCleaver - 06 May 2004

Someone may be interested in this. It replaces bin/login with a version that works with CairoRelease

#!/usr/bin/perl
sub BEGIN { $ENV{PTKDB_STOP_TAG_COLOR} = "yellow" }
#
# TWiki WikiClone (see wiki.pm for $wikiversion and other info)
#
# Copyright (C) 1999 Peter Thoeny, peter@thoeny.com
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details, published at
# http://www.gnu.org/copyleft/gpl.html

use CGI::Carp qw(fatalsToBrowser);
use CGI;
BEGIN {
    # Set default current working directory (needed for mod_perl)
    if( $ENV{"SCRIPT_FILENAME"} && $ENV{"SCRIPT_FILENAME"} =~ /^(.+)\/[^\/]+$/ ) {
        chdir $1;
    }
    # Set library paths in @INC, at compile time
    unshift @INC, '.';
    require 'setlib.cfg';
}
use TWiki;

$query = new CGI();

main();

sub main
{
    my $thePathInfo = $query->path_info();
    my $theRemoteUser = $query->remote_user();
    my $theTopic = $query->param( 'topic' );
    my $theUrl = $query->url;

    ( $topic, $web ) =
        TWiki::initialize( $thePathInfo, $theRemoteUser, $theTopic, $theUrl, $query );

    my $url = TWiki::getViewUrl( $web, $topic );

    $url .= ( '?' . $query->query_string() ) if $query->query_string();

    TWiki::redirect( $query, $url );
}

-- MartinCleaver - 16 May 2004

The "getViewUrl( $web, $topic )" above should be: getViewUrl( $TWiki::webName, $topic)

in order for the logon to work with the free skin and across multiple webs.

-- RandallGaz - 17 Jul 2004

Request for enhancement: logout!

My company is evaluating TWiki for use on the intranet but the evaluator raised the question: How does a user logout?

I realise closing the browser will terminate the session, but when you're using Mozilla with multiple tabs this becomes a big pain in the butt. Admittedly I don't have much of a clue as to how this plugin works but I think it should be trivial to add a bin/logout utility.

-- MichaelHenry - 25 May 2004

Any chance we could update this valuable plugin for CairoRelease? If someone would help me with rounding up and applying all required patches (Martin?), I'd repackage the plugin and repost.

-- LynnwoodBrown - 29 Jun 2004

Sure. I'll make a release in the next few days, time permitting.

-- MartinCleaver - 18 Jul 2004

While you're at it, Lynnwood or Martin, could you stuff it into CVS as well?

-- CrawfordCurrie - 19 Jul 2004

Any reason why I should not replace the existing SessionPlugin with the new improved Smart one?

-- MartinCleaver - 19 Jul 2004

Ok, its now in place of SessionPlugin and in CVS. Please test and I'll trash the old SmartSessionPlugin topic.

-- MartinCleaver - 29 Sep 2004