stale_content1Add my vote for this tag create new tag
, view all tags
I think I've come up with something better than the normal $doRememberRemoteUser option in TWiki.

Rather than the conventional:

  1. Forcing every user to authenticate even to view
  2. Attempting to remember User-to-IP address mappings (like doRemember does)
  3. Preventing a user from ever having user-specific settings (because view won't remember them)

Just make this small change to TWiki.

RCS file: TWiki.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
> # By Ted: To fix trouble with remembering auth information
> if( "" ne $ENV{REMOTE_USER} )
>    { $scriptUrlPath =~ s/%PUT_NOAUTH_NO_HERE%//; }
> else
>    { $scriptUrlPath =~ s/%PUT_NOAUTH_NO_HERE%/no/; }
> # End auth fix
> # By Ted: To fix trouble with remembering auth information
>     if( "" ne $ENV{REMOTE_USER} )
>        { $scriptUrlPath =~ s/%PUT_NOAUTH_NO_HERE%//; }
>     else
>        { $scriptUrlPath =~ s/%PUT_NOAUTH_NO_HERE%/no/; }
> # End auth fix

In other words, while initializing $scriptUrlPath, look for %PUT_NOAUTH_NO_HERE% and replace it with a no if no one has logged in and replace it with nothing if someone has logged in. (the significance to this will become very apparent soon)

Then go to the twiki root directory (where bin resides) and do this:

mkdir auth; mkdir noauth cd auth; ln -s ../bin; cd .. cd noauth; ln -s ../bin; cd ..

And then drop an .htaccess file in the noauth directory that just has:

Options FollowSymLinks

drop an .htaccess file in the auth directory that has:

Options FollowSymLinks
<Files "*">
    require valid-user

Finally, edit TWiki.pm and change $scriptUrlPath to be:

$scriptUrlPath = "/path/to/twiki/%PUT_NOAUTH_NO_HERE%auth/bin";

and after that, it's not very intrusive at all. It requires NO OTHER CHANGES. The elegance comes from:

  • The symlinks to bin from auth and noauth will still reference the root twiki directory when scripts access .. by the nature of the symlink
  • Since this wraps around the entire bin directory, it affects more than just view. Most other similiar fixes implement some sort of viewauth. This prevents that entirely.
    • What allows this to happen is the modification of the $scriptUrlPath which works behind the scenes to make all of this happen, unlike other fixes which require a great deal of changes to move to a viewauth type system

I have this up and running at http://www.osufirst.org/ on a small TWiki web there. After a user logs in, all of their user preferences are retained. If I hadn't made these changes, they would be TWikiGuest on every view page and their actual WikiName on every preview page.

Does anyone see any problems with this? Does it have enough merit to warrant thinking about adding something like this to the TWiki distribution? It would just require:

  1. Changing the directory structure by adding those symlinks
    • could be done through a script
  2. Adding those .htaccess files to that directory structure
  3. Changing TWiki.pm
  4. Changing TWiki.cfg

Really, it requires even less changes than that. The above change to TWiki.pm works fine with existing configurations; the changes simply make no difference.

Any thoughts?

-- TedPavlic - 15 Jul 2003

I like the idea - it's better than auth prefix that we now have. If I understand it right, it would work exactly as I suggested in ImproveViewAuthentication, but would require much less changes. (The only question is: can it be made to work correctly on a filesystem without symbolic links? Windows support is important to me.)

However, I would like the directory layout to be configurable - for example, I want to be able to put NonAuthenticatedMode scripts in TWiki's root directory, and AuthenticatedMode scripts - in a/ subdirectory. This can be easily accomplished by using two configuration variables - $scriptUrlPathNoAuth and $scriptUrlPathAuth - and assigning the value of one of them to $scriptUrlPath.

-- PavelGoran - 15 Jul 2003

In response to PavelGoran:

  • Configurable auth and noauth directories
    • I thought about having a configurable auth and noauth directory, but at the moment I was looking for a way to change TWiki the least and still have the same TWiki libraries be able to operate a TWiki site with a TWiki.cfg file that was not setup for this auth vs. noauth confgiruation. If this seems like a good production feature though, making it more configurable seems like a good thing to do.

  • Windows users not using symlinks
    • With regard to the symlinks, the power of using the symlinks is that it does not require that separate bin directories are maintained. When I install a plugin that adds something to /twiki/bin, I can still extract all of the plugin's files as usual and forget that I even have a special auth/noauth engine running in background. However, if a windows user is willing to sacrifice this flexibility, (s)he should still be able to make use of the changes to TWiki.pm. It simply would require that every time /twiki/bin goes through a change, /twiki/auth/bin and /twiki/noauth/bin also go through the same change.
      • The major problem here is that /twiki/auth/bin/../ is not the same as /twiki/ as it would be with symlinks. If only Windows shortcuts were implemented as real symlinks.
      • Does this cause a problem? Do scripts need to ever directly access ../? Should they be ensured that ../ is /twiki/?
    • Another possibility for fixing the windows problem might be to look into different web server configuration tricks that might be able to alias /twiki/auth/bin and /twiki/noauth/bin to the same /twiki/bin directory while making authentication required for one alias and not required for the other.
      • This fixes the problem mentioned above with symlinks. No symlinks are required and /twiki/auth/bin/../ does still point to /twiki/ since on the filesystem /twiki/auth/bin/ is really /twiki/bin/.

-- TedPavlic - 15 Jul 2003

  • I also want to stress that this change requires NO CHANGES to be made to TEMPLATES that already reference view. By changing $scriptUrlPath, templates automatically point to appropriate auth links. It really is a very small change at a central location that has a large ripple through the rest of TWiki.

-- TedPavlic - 15 Jul 2003

  • As a side comment, it would be nice if TWiki.pm used sessions internally to toss information like this around. This would prevent all of the mess above, but it might make authentication more complicated, though I think an authenticated session could be created in much the same way as I change the $scriptUrlPath above.
    • It's worth researching creating a version of TWiki.pm that uses Perl sessions in order to store authentication information.
    • At the instant $ENV{REMOTE_USER} gets filled, a session could be created with username stored within it.
    • Sessions could be passed with cookies and/or by posting a session ID on the URL of each TWiki script.
    • If a session existed, set WikiName from inside session. Otherwise, assume TWikiGuest.

  • This appears to be a pretty easy feature to implement, but it requires the additional overhead of keeping session information in a temporary location on each server. (and that invites all the problems that go along with that)

  • However, this allows the fix to work for both Windows and Linux (and other) users.

  • AND this feature makes it much simpler to copy and paste URL's to non-authenticated users, which is a problem all of the suggested fixes have thus far.

  • NOTE: Some work has already been done on this with TWiki:Plugins/SessionPlugin. I'm not sure the authentication routine they use is all that grand. I envision a much simpler solution that doesn't require any major change to the way people authenticate to TWiki. That is, I'm looking for a way to make TWiki work nearly exactly the same as it works now but just happens to transparently use a session (with ID located in %SESSIONID% or something) to keep its memory. In fact, it would be nice if the Plugin could search through every template as it displays and add a ?session_id=%SESSIONID% automatically to help users who don't want to use cookies (or viewers who don't have cookies).
    • I may put such a plugin together tonight. If I do, I'll start a separate thread for its evolution and discussion.

-- TedPavlic - 15 Jul 2003

I rewrote TWiki:Plugins/SessionPlugin to support all of its previous features plus ones that allow it to remember authentication WITHOUT the need for an external logon script. The rewrite can be found at TWiki:Plugins/SessionPluginDev (attached).

I plan to update the documentation and add a configurable feature which will allow the plugin to automagically change all links to have a:


at the end of them (for users who don't use cookies). Once I do this, I'll package it all up and release it as some sort of alternative Plugin for TWiki:Plugins/SessionPlugin. I wanted to put it out as SmartSessionPlugin, but SessionPlugin is currently hardcoded into the Beijing TWiki. frown

-- TedPavlic - 16 Jul 2003

Check out TWiki:Plugins/SmartSessionPlugin. I'm really happy with how it turned out. This is a very easy and very elegant way to solve this problem.

-- TedPavlic - 17 Jul 2003

TWiki:Plugins.SessionPlugin has been replaced with TWiki:Plugins.SmartSessionPlugin


Is this already merged to core when Session management was merged?

-- RafaelAlvarez - 24 Aug 2008

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2008-08-24 - TWikiJanitor
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.