create new tag
, view all tags
At present, there are two scripts that are normally not authenticated, but can work in "authenticated" mode; these are ViewCgiScript and RdiffCgiScript (named viewauth and rdiffauth in AuthenticatedMode). Non-authenticated versions of these scripts redirect to authenticated ones when they detect the inability to read something (the requested topic or one of included topics). This works satisfactorily in many cases, but the existing implementation could/should IMHO be improved in some ways:

  1. SearchCgiScript should be able to work in AuthenticatedMode (that is, it should redirect to searchauth when appropriate) - without SearchCgiScript authentication, WebSearch doesn't find topics that TWikiGuest is not allowed to view (unless RememberRemoteUser is enabled), which is quite frustrating.
  2. AuthenticatedMode should be retained once it is entered - that is, links from pages generated by AuthenticatedMode scripts should point to AuthenticatedMode scripts when appropriate (for example, viewauth -generated page should link to viewauth in normal WikiLinks and to rdiffauth in the BottomBar).
    • This is a debatable feature. I find it appropriate, because I use OperaBrowser and without this feature, I never have view-restricted topic links coloured as "visited". On the other hand, this would break visited links colouring in NonAuthenticatedMode if they (links) were visited in AuthenticatedMode, and vice versa - but this is not a problem if a user (almost) always works in one of modes. Also, this could be made configurable through UserPreferences.
  3. AuthenticatedMode activation logic in RdiffCgiScript should be fixed - it doesn't work when view restriction is done on topic level (with ALLOWTOPICVIEW).

Are these changes acceptable/desirable? (I would like to implement them, later I'll describe how.)

-- PavelGoran - 29 Jun 2003

Switching to AuthenticatedMode for SearchCgiScript can be implemented easily - just call TWiki::Search::searchWeb with "inline" feature enabled (to get search results as a string, instead of transferring them directly to the client through print calls), then check whether some topic failed to be read with current permissions, and switch to AuthenticatedMode if this is true - just as it is done in ViewCgiScript and RdiffCgiScript.

Retaining AuthenticatedMode can be achieved by creating the additional variable $authScriptSuffix and the corresponding TWikiTag %AUTHSCRIPTSUFFIX% that are empty in NonAuthenticatedMode and are equal to "auth" in AuthenticatedMode. These variable and tag should be used when generating URLs that point to one of "two-mode" scripts. The current mode can be derived from the presence of REMOTE_USER environment variable. This way, AuthenticatedMode will be activated not only when executing one of "...auth" scripts, but also when executing any of "naturally authenticated" scripts such as EditCgiScript - which is appropriate behaviour. Introducing this feature means doing minor changes in many script files, in all (or almost all) templates and in WebSearch topic.

AuthenticatedMode activation logic in RdiffCgiScript is trivial to fix - this change should be done anyway, so I'll provide the patch shortly (See DiffsFunctionDoesNotAuthenticateProperly for the patch -- PavelGoran - 06 Jul 2003).

The proposed changes will I hope bring "view authentication" to a reasonable level of usability (apart from SecuringAttachments, which is the separate issue that I want to resolve too).

-- PavelGoran - 30 Jun 2003

Surely any script should be able to result in AuthenticatedMode being entered? For instance, the ChangesCgiScript might occur on a protected section of the site. It shouldn't fail, it should handle the situation. I think we need a general solution that will work for any solution.

In CommonFrontEndCgiScript, Colas has recently (17 Jun) proposed that, instead of one view script, there should be 4 scripts just for viewing.

I am concerned the changes he has suggested together with yours is going to lead to more unmanageability in terms of script proliferation.

Pavel, do you think we might be able to use MegaTWiki's MegaTWikiServiceRegistrationMethods (See PeterNixon, 12 Jun 2002) to implement a CommonFrontEndCgiScript?

I'll be on TWikiIRC for the next few hours.

-- MartinCleaver - 07 Jul 2003

Pavel's already made some comments there (which directed me here), so I figured I'd check out this page and add a comment.

I'm proposing a different set of changes at BetterThandoRememberRemoteUser that change TWiki.pm by adding about six lines. These changes allow every script in bin to move into AuthenticatedMode and stay in AuthenticatedMode without the use of $doRememberRemoteUser. It also automatically handles other scripts that do not require AuthenticatedMode. It also does NOT require any extra work to make teaplates point to the correct view and rdiff URLs. The use of $scriptUrlPath touches them behind the scenes. Otherwise, TWiki.pm would have to smartly parse every template and add "auth" in some places and not add it in others.

The only problem is that currently its simple elegance depends on symlinks. A windows user could try maintaining three separate /twiki/bin directories (in other words, after changing /twiki/bin copy those changes to /twiki/auth/bin and /twiki/noauth/bin), but if a script ever tries to look at ../, it will not see /twiki/ as the symlink version will; this could cause a problem.

BetterThandoRememberRemoteUser is a simple change which takes advantage of:

  • The power of symlinks
    • User only needs to maintain /twiki/bin
    • But gets advantage of having /twiki/auth/bin and /twiki/noauth/bin
    • Yet /twiki/*auth/bin/../ looks like /twiki/
  • The ability for an .htaccess to affect all directories underneath it
    • So /twiki/auth/bin always authenticates because /twiki/auth/.htaccess requires it
    • And /twiki/noauth/bin does whatever authentication is initially required in /twiki/bin/.htaccess because /twiki/noauth/.htaccess adds no other restrictions.
  • Modifying $scriptUrlPath in TWiki.pm dynamically
    • This change allows all scripts to be touched by AuthenticatedMode persistence
    • This change does not require any other changes to any other TWiki software
      • This includes templates -- templates that already reference view do not need to be updated as their %SCRIPTURL% will automatically change since $scriptUrlPath is being modified behind the scenes dynamically by TWiki.
    • This change is always turned off until invoked directly, so making the TWiki.pm changes can be done months before reconfiguring the site.

For more details, check out BetterThandoRememberRemoteUser.

-- TedPavlic - 15 Jul 2003

Also see TWiki:Plugins/SessionPlugin for an alternative sort of "solution" to this problem.

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

Good work Ted!

-- MartinCleaver - 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

The SmartSessionPlugin is a bit different way of solving these problems. The difference is that its "magic" isn't in effect until the user explicitly does something that requires his/her to authenticate (edit or whatever). The plug-in makes AuthenticatedMode persistent, but doesn't do (and, I'm afraid, can't do) anything to bring a user to this mode when it's needed (for example, when the given topic is unreadable by TWikiGuest).

-- PavelGoran - 18 Jul 2003

Couldn't view be modified to redirect the user to the bin/logon page if they're the guest? I suppose that's problematic because bin/logon is tied to TWiki:Plugins/SessionPlugin and thus cannot be included within bin/view... However, why not add a generic logon script to the TWiki distribution? It could be modeled exactly like the bin/logon that comes with TWiki:Plugins/SessionPlugin.

Would it be so horrible to have the view script redirect to such a logon script first before moving someone to an oops page? That is, if they're guest, see who they really are first. After that, give them the oops.

I still would rather not have all of these auth symlinks and such running around if all we're trying to do is some very specific little problems with TWikiGuest. It seems dumb to have an rdiffauth and viewauth script when all you're trying to achieve is a logon. Take advantage of redirection and redirect to something that simply authenticates and redirects to the original page. Why is that a bad thing? Am I missing the point?

I'll try to submit a patch for view that does this... but perhaps I'm missing something and this will become apparent to me then. I'm not trying to be difficult here; I just think that going down this current line seems to lead no where but trouble. I'm searching for a flexible and very GENERAL solution that patches up a lot of problems at once rather than forces future users into much more complicated precautions as new features arrive.

-- TedPavlic - 21 Jul 2003

Maybe what we need is some kind of wrapper around SmartSessionPlugin. %LOGIN% if current user is not authorised will render "Please login" link. If it is, will render link to the user homepage in MAINWEB.

-- PeterMasiar - 22 Jul 2003

I suggested something similar in AuthenticatedModeDiscussion. Basically, when any page redirected to an oops page, it first checked to see if the user was TWikiGuest. If it was, then instead of redirecting to an oops page, it redirected to bin/logon which would then redirect to the original page that had the access restrictions. If then after the user had logged in there was still an access problem, it would redirect to an oops page.

That seems fairly transparent and takes care of the issues of having a user logged in as guest trying to access a page (s)he really does have access to and getting rejected just because (s)he hasn't taken the time to authenticate by editing anything.

So I think that would work. I'm tempted to say that would work really well. However, it puts a strong depedence on SmartSessionPlugin. I'm not sure that TWiki needs session management in its core. Its a nice feature to have, but with transparent CGI session IDs, it still screws with the URL of every page (which makes it difficult to refer to URLs when passing them on to others), and otherwise it requires cookies, which may or may not be reasonable (other authentication schemes all over the net are okay with this, but if there's a non-cookie way to do it, that's probably more desirable).

So I think looking at CommonFrontEndCgiScript would bring some neat solutions. I'm not saying Common... is the right way to go, but I think it's the right line of thinking. There are other cool things that are gained by having a CommonFrontEnd... The only problem is that with one script with which everything sits behind, that means that Apache authentication may not be as easy to use. It may require CommonFrontEnd... being able to redirect to an auth.tmpl where users have to logon on a webpage rather than in a popup dialog used by Apache's basic authentication. Personally, I'm okay with this. There's a lot of controversy over whether or not this is a good idea to put authentication within TWiki.

Some bad points:

  • It may make it more difficult for other users to use their own authentication databases (i.e., LDAP, Samba, PAM, etc.)
    • Some thought can be put into how to make this pluggable. That is, it may be easy to create a plugin that calls some sort of "authentication handler" that does auth rather than the default way.
  • Puts the burden of security on TWiki and not on Apache
    • Are TWiki developers ready for this? I think so. There are plenty of good modules available for Perl to make authentication at least as good as Apache's basic authentication.

Some good points:

  • Makes it easier to implement a TWiki administration system where users can be easily added, subtracted, etc.
  • Cleans up the look of authentication and makes it more sensitive to changes in skin.
  • Makes authentication much more configurable. No more adding or subtracting .htaccess files in particular places. Now just set a TWikiVariable somewhere that flips it on or off or makes it dynamic.
  • Opens up more of an opportunity for more interesting authentication -- groups and subgroups and authentication based on group rather than user...
    • This probably goes counter to WikiCulture
    • This is already implemented within TWiki. Really only a need to verify a user (and not his or her group) is all that's needed.

And I'm sure there's plenty more points that can be added under both. I lean more toward having a CommonFrontEndCgiScript that does use an auth.tmpl to authenticate with an authentication handler allowing for other methods of authentication to be added as easily as adding a plugin.

Perhaps this whole discussion should be moved into one forum, like AuthenticatedModeDiscussion?

-- TedPavlic - 22 Jul 2003

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2005-05-25 - AndreUlrich
  • 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.