Tags:
create new tag
, view all tags
(Moved from AuthenticatedMode. -- PavelGoran - 22 Jul 2003)

So I've mentioned this in another posting, but I wanted to direct attention specifically to it here.

Right now I'm not comfortable with heading down this path of creating various AuthenticatedMode scripts. I know that it's very tempting to do this at first. I think most every administrator's first thought was to make a symlink to a script that authenticates and use it instead. That was my first thought. Then I realized the problems with all the templates that already had the NonAuthenciatedMode versions hard-coded into them... So I thought up the BetterThandoRememberRemoteUser which was a quick stopgap solution before I found (or wrote) something that took advantage of sessions, for example (see TWiki:Codev/SmartSessionPlugin). But that still leaves the problem that if TWikiGuest views a page that require a particular access level, they will be sent to an oops page. Following in the example which was started to be set by TWiki:Codev/SessionPlugin, why not create a bin/logon addition to the TWiki distribution that simply has in it something like (taken from SessionPlugin):

$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 ) =
        &TWiki::initialize( $thePathInfo, $theRemoteUser, $theTopic, $theUrl, $query );

    my $url = &TWiki::getViewUrl( $webName, $topic );
    &TWiki::redirect( $query, $url );
}

Now when a script decides on whether or not someone has the right access level for things, if they are logged in as TWikiGuest, redirect them here, which will simply log them in and then redirect them on.

Granted, the getViewUrl probably should be changed to something which pays more attention to the action which caused the redirection to logon, but I think this shows a pretty decent proof of concept.

Rather than creating AuthenticatedMode and NonAuthenticatedMode scripts, why not redirect to a script that is ONLY MEANT for LOGGING ON and then have that script redirect to the original script?

The only way this would work, of course, is if some sort of session information was passed back and forth. TWiki:Plugins/SmartSessionPlugin handles this well-enough with cookies and/or transparent CGI session ID passing, and this is basically how most authentication schemes are done in other parts of the web. (using $doRememberRemoteUser in TWiki.cfg is an OK stopgap solution to this too)

In summary, the creation of multiple different "modes" of scripts in order to massage Apache into behaving like a real authentication engine seems silly. There are plenty of other good examples of authentication working seemlessly available already on the Internet. We should be following either in their example or at least be driven by the fact that they are simple and do not require these odd measures and thus we should not require these odd measures. To me, it seems like the problem is sometimes we need to authenticate, and right now the answer seems to only be so let's create copies of scripts that require authentication and others that do not, when I think the answer should probably be, let's either stop depending on Apache to authenticate for us (create an auth.tmpl that does a logon) and find a new way to pass authentication information from script to script (sessions provide a good templates for this) or stick with using Apache and just force people to authenticate when they need to authenticate and just redirect them back to the page that needed the authentication in the first place.

So when you're setting up your website, keep these things in mind. Do you really want to:

  • Create extra scripts to manage in your bin directory
  • Cause one page to be accessed by multiple URLs
    • Thus making copy and pasting URLs for communication more complicated
    • Thus making hard-coded URLs in scripts very problematic

Is that worth it to you? And if it isn't, doesn't seem like there is a better way? I'd advise you to look for that better way.

-- TedPavlic - 21 Jul 2003

 
Rather than creating AuthenticatedMode and NonAuthenticatedMode scripts, why not redirect to a script that is ONLY MEANT for LOGGING ON and then have that script redirect to the original script?

Because this will not work in the majority of scenarios that many people wish to run TWiki in. Simple as that. (The redirect will cause you to lose the information you just gained in majority setups)

Remember the two majority cases:

  1. Authenticating everything can be done by using Apache( /your web server) - and indeed is IMO the best way to do things - since it leaves the base code unchanged.
  2. Authentication only required for some actions - specifically changing content - then again this is best done using Apache( /your web server)

The less common case is authentication (confirmation of id) required for content. This boils down to two main use cases: (even so, the second is often denoted as two things)

  • Confirmation of id. (Required for customisation of content)
  • Authorisation & access to content

Confirmation of identity means the webserver needs to have information from the user as to who they are. Approaches that can be taken: (non-exhaustive list)

  • Authenticate the user for everything using HTTP authentication
  • Authenticate the user for one thing, and...
  • Remember who they are based on IP
  • Force them to store a cookie
  • From that point on remap their URLs based on their login.
  • Redirect any accesses to customised content through an aliased script. (ala viewauth)
  • Redirect any accesses to authenticated content to a single script, which then performs the actions of the requested only if the user authenticates themselves. ie you have something like: Where auth is a script not a symlink to a directory.

The current approaches work for the basic tenet of a Wiki - that access to data for viewing is always allowed, only changes to content are sometimes restricted. (Authentication isn't required for the majority of Wikis)

The auth script would simply be there to enforce authentication. Authorisation & Access would continue to be enforced by the view/etc scripts at this stage. However I do NOT agree that doRememberRemoteUser is bad - it is extremely useful - I use the fact that it is switched on with TWiki.org to customise my user interface on TWiki.org. It is a stupid approach for authorisation of content, but that is a very different story - authentication isn't just used for that.

In my experience, using Authorisation & Access in a Wiki is relatively rare. (I use it and have set it up for other people, but many people don't)

There's more to user tracking than authorisation & access. I'm not saying we shouldn't do it, but for the majority case the current approach of using Apache for authentication is a good one, but needs a simple tweak - which does not mean session management should go into the TWiki core, and does not require session management to go into the core. (Session management is useful only once you have the basic authentication mechanisms in place)

After all, in the beginning there was no authorisation required. Then came authorisation for editting, and session management has handled transparently by apache. Then view authorisation came for specific pages, and that worked pretty well, but has some corner cases which people are hitting, but generally worked as long as an "oops" redirect to viewauth was always performed. Then a hole was found in the form of the rdiff, so authorisation needed to be bolted in there as well.

What this boils down to is the tweaks that have been put in place are hitting their limits and something more "radical" needs to be done. Other people have indicated they need other authorisation schemes, that they can subvert the current authorisation schemes by adding in plugins, addons and so on. (*) IMO this means that the TWiki filesystem has to be the thing that enforces this - but that requires a more major modifications than most people are able/have incentive to put in at present.

    (*) For example, do any of TWiki's publishing systems enforce the authorisation aspects? Does it? I know the answer - do you? wink should you need to know ?

As a result I would be in favour of largely leaving the current system of auth versions of rdiff & view in place, as is, the creation in the meantime of an authorisation script, through which all authorisation must go through which then calls the appropriate script (rather than requiring cookies/etc). This is a low overhead change in many respects and heads down the "correct" route IMO. (As well as not relying on OS specific aspects of other solutions)

> I'd advise you to look for that better way.

Bear in mind after all the fact that the majority of people just do not use these features. (The common things should be simple, the less common things should be possible.)

-- MichaelSparks - 21 Jul 2003

Comprehensive list of possibilities, I think, I invite other suggestions. (I personally believe in enabling cookies but that's a moot point).

I've previously suggested (I've lost the reference) a scheme similar to Ted's. My primary concern in all of this is to minimise the complexity of stuff in the bin directory. Intuitively I think that CommonFrontEndCgiScript is the way to go as I think this would also address the issues mentioned in PluginBinNameClashes.

If anyone wants to discuss I'll be on TWikiIRC.

-- MartinCleaver - 21 Jul 2003

If a CommonFrontEndCgiScript was used, which could eliminate the need for passing cookies entirely, wouldn't that imply that an auth.tmpl would be required? That is, wouldn't that give up authentication based off of Apache? I'm not saying I'm not okay with this, but it seems like many people want to stick with Apache-style authentication.

The thing is, most people who use Apache-style authentication use Basic authentication, which is not very secure. At least using digest (or something similar) would add a little more security there. Either way, right now the big arguments I've seen against having a separate logon script had to do with security holes, but I hardly think depending on Apache adds that much security.

From my experience, Apache's a good starting point for authentication. It's easy and quick, but it's not very customizable. It's for simple things -- directories that are often accessed with Indexes on -- similar to HTTP-style FTP.

As authentication gets more advanced, people typically drop the dependence on Apache authentication and code their own auth scripts up. This allows for a bit more customization and still has as much security as Apache's authentication (and allows for conceivably more).

I recognize that there are plenty of tradeoffs that need to be made, and perhaps it's more obvious that some tradeoffs are easier to make than others, but I still think there are nicer cleaner solutions out there that have not yet been put into words on these forums yet.

Anyway, I'm going to finish development on TWiki:Plugins/SmartSessionPlugin and then patch a few other things up. I still think TWiki:Plguins/SmartSessionPlugin has a lot of merit on its own, but I agree that there is a better way out there to solve all of these AuthenticatedMode related problems. I'm not trying to upset anyone here or anything like that, but I'm trying to stir up some conversation. I've noticed that the TWiki community seems to be filled with a number of people who have only had a few days worth of Perl experience and perhaps no experience administrating web servers, but I know there are a few people out there who have been around long enough and have had problems like this before that will volunteer some good alternatives from their own pasts. I'm trying to drum up more conversation to get these people to come out of the wordwork and give some ideas about a way to solve these problems that has a greater sense of propriety than everything thus far.

-- TedPavlic - 21 Jul 2003

The attached trivial script shows how the final approach I discussed can be implemented. This script is called as follows:

Where "view" is any of the scripts in the bin directory. Using Apache for auth you would now simply have in your apache config:

   <Files 'auth'>
      require valid-user
   </Files>

Any script that is called would be required to check that users are authorised to perform the action, and if they are not authorised to deny the action. They wouldn't be required to handle authentication however. If authentication - identity checking - has not occured then they should redirect to the URL formed by changing:

  • %SCRIPTURL%/theScript/Junk
To:
  • %SCRIPTURL%/auth/theScript/Junk

Clearly the auth script could be made to send back the appropriate HTTP response to require authentication, but would be duplicating effort best actually expended in the webserver. (Greater number of eyes checking the code in the apache/IIS world and if someone is running a webserver they'd better know how to admin it as well - though the TWikiUnixInstaller should help them with choosing a better auth mode.) After all this simple script at the moment can have auth performed by either apache or having hooks for cookie based auth, or adding in session information - since it can very happily change the PATH_INFO or any other parts of the environment required by the subsystem below which has to trust it/apache.

What this doesn't address is the authorisation aspects I indicate above, which are more complex, and quite frankly need to be resolved by passing information further through the system that TWiki does at present. Identity checking (authentication) is but one small aspect of the whole picture - as anyone who's dealt with this more than once will be painfully aware.

Historically however, this wasn't a problem really with TWiki with the culture being one of openness and anyone is allowed to access/view/change everything.

-- MichaelSparks - 22 Jul 2003

I see very little difference in that solution than what I suggested in BetterthandoRememberRemote user. There's still a schism between authenticated and non-authenticated content. I chose not to use a script like yours because I didn't want to add another script into the mix.

Both the fix above and BetterThandoRememberRemoteUser require changes to be made to TWiki.pm (see the patch in BetterThan...) that would only the fly change URLs referring to non-authenticated content to authenticated content thus to ImproveViewAuthentication. If both require patches to TWiki.pm to work smoothly and transparently, I see little difference between them, except that in the auth script example Windows users are a little happier (does CygWin support symlinks? (that relates to BetterThan...)).

But putting aside the Windows concerns, that still means this has the same fundamental problems as BetterThan... Once a user logs in, it changes all of the URLs that (s)he accesses from that point on. The user would need to know when to bookmark a page to prevent less hassle... When copy and pasting links to others (or in the unfortunate times when the user included an internal link to a hard URL), the user would have to remember to strip out the auth. That is, just because I've edited a page doesn't mean I want to restrict all views to it to be auth views. Thus, I need to strip out the auth whenever I pass on a link.

That was a major motivation behind using session management to do this in a cleaner way. Granted, turning on transparent CGI session IDs pollutes the URL once again, but transparent CGI session IDs are only used when cookies are refused, and IP and user matching are used to reinforce security. So in the majoritiy of cases, scripts stay authenticated without anything in the URL needing to be tweaked.

To add to that then, scripts that redirect to oops pages could first redirect to the bin/logon page IF THE USER is a TWIKIGUEST. That page would then authenticate, setup a session, and then redirect to the original requested page. This, to me, fixes the problem of having a user logged in as TWikiGuest being refused from an access controlled page simply because they haven't taken the time to logon yet. This forces them to logon at the point when authentication is needed and THEN if they aren't the proper user, actually redirect them to an oops page.

So that seems clean enough, but it requires sessions. That's perhaps too much for the main distribution of TWiki to swallow.

So I think the issue now is finding a way for TWiki to wrap up all of this access control stuff into one easy and clean non-session and non-URL-changing package. There are plenty of solutions which have been suggested that either mangle the URL or pass information around via CGI or cookie based sessions. The challenge is finding a way to not do either of these. That's why I thought Martin suggested CommonFrontEndCgiScript. And that's where I think most effort should probably be focussed at the moment. There are lots of other benefits to having a CommonFrontEndCgiScript that benefit WikiCulture as well.

So I'm not saying CommonFrontEndCgiScript is the solution that TWiki needs, but I think thinking down that path is probably going to lead to somewhere more useful than these other ones.

-- TedPavlic - 22 Jul 2003

>>The challenge is finding a way to not do either of these. [Cookie or URL mangling]<<

With a little creative coding, The HTTP header: "ETAG" can be used for session tracking. Using the "ETAG" this way would still be fully consistent with its standardized usage and well supported by browsers/proxies. Losing session information would only happen when the browser flushes the site's pages out of its cache.

Also with a bit of creative coding, the standard Authorization TWiki currently uses can be augmented to hide the ugly logon screen most browsers produce: Issuing a temporary redirect to a "username:password@www.somewhere.com" followed immediately by another redirect to "www.somewhere.com" will cause the browser to remember the authorization credentials without obviously betraying them in the "address" field on the screen (albeit only for that session). Coding a nice HTML form which passes credentials to the server and the server doing the double redirect should be straightforward.

Additionally, Microsoft IE provides a proprietary local storage area at the browser separate from cookies, working almost identically, and cannot be "turned off" (as of yet). I'd hate to see TWiki use this method for session tracking, though. smile

In my humble opinion, most of this discussion really revolves around finding workarounds for the fact that Apache's standard authorization mechanisms do not set the username environment variable(s) for access areas not controlled by a "require" directive, even if the browser sends it. Might it not be more prudent to "fix" that problem? The Apache API allows for custom authorization handlers. If mod_perl is installed, not only can it be written in perl, but, if carefully written, activating the custom handlers can be done in an .htaccess file and used in a non-root (ISP) configuration.

By writing custom authorization handler(s) for Apache, any and all access control methods currently used and/or discussed here can be fixed/implemented completely transparent to the scripts hosted at the server and without unneeded redirects. Just a little creative coding could also create a logout mechanism for the standard authorization. I believe there is enough sample code at CPAN and elsewhere for a apache/mod_perl coder put together such a solution. The core TWiki code would then be relieved of performing authorization/access checking duties.

I think the only proper alternative would be for TWiki to handle all authorization tasks within its core (or plugins) and not rely on Apache for authorization. By doing this, most of the flexibility I mention above can be achieved without writing Apache and/or mod_perl handlers. The "view" to "viewauth" redirect is an inelegant solution: Either apache's authorization mechanism should be enhanced to support the cases Twiki wishes for, or TWiki's scripts should just issue the HTTP "WWW-Authenticate" headers itself.

At the very least, TWiki's current "doRememberRemoteUser" implementation can be improved somewhat by properly handling the HTTP "Via" header tacked on by trusted proxies.

-- TomKagan - 22 Jul 2003

I think those are a lot of good comments. I never thought of using ETAG for this particular purpose, and I'm not quite sure it's necessarily the most appropriate use of it. I'd be afraid of confusing other things that use ETag. I've always heard of ETag being involved with caching, for example.

With regard to modifying Apache, one would have to be careful about this. Not only does it put an odd dependency from TWiki to a particular modification to Apache (yes, assuming someone is using mod_perl, it may not be difficult to install a TWiki mod into Apache, but not everyone has that sort of access to Apache), but it also makes it tempting to add functionality to Apache that maybe doesn't make much sense.

That is, I know it seems like Apache should be able to report the REMOTE_USER to any script in a directory that also has other scripts in it that have been authenticated. However, from Apache's point of view, this doesn't necessarily make any sense. You'll notice that Apache's own documentation reports that require is allowed in <Directory>...</Directory> as well as .htaccess. However, we see it within .htaccess modifying <Files>...</Files> We see the same restrictions on AuthType, AuthUserFile, AuthName, and AuthGroupFile. This implies to me that I could very well see all of those directives possibly defined on a PER-FILE BASIS. That is, even though files live in one directory together, they might all SEPERATELY have different requirements for authentication (remember there is a Satisfy as well). Apache simply cannot assume any relationship among files in one directory.

If a modification was made to Apache, it would have to add some sort of GetAuthInfoFrom tag which borrows authentication information from another script if that script has any provided to it. However, how would Apache "remember" this information? How would Apache remember that a particular user already logged in at one script from one IP, so it should assume that requests from that same IP also should go to the other script? It would have to store some sort of cookie or something along those lines.

Apache simply does not have an easy way of doing what we want it to do without it doing exactly what we're talking about doing here. So I would say modifying Apache isn't going to help. It would add a great deal of complexity to Apache -- probably more than what would be added to TWiki.

Now, as mentioned, clever usage of how usernames and passwords are passed to Apache can be used too. And that brings me to a point I'll make in a moment.

I'm on the side of the argument for having TWiki do its own authentication scheme that does not necessarily have anything to do with Apache. This would require some sort of auth.tmpl that would allow for the entry of username and password and would pass that to an authenticateUser which would be overridden by an authenticateUserHandler provided by a plugin (this would be one of the examples where only one type of this plugin could be installed at once).

Now, getting back to the clever usage of Apache username and passwords in URLs, why not do what I just said, but make the default operation to pass the username and password information into TWiki such that it invokes normal Apache basic authentication, or something like this?

I still would rather see everything handled from a CommonFrontEnd... but a good start at authentication could simultaneously provide for internal TWiki authentication that simply uses Apache's basic authentication on the backend and has plenty of room to easily expand to other authentication.

And of course, if any page was accessed that had particular access permissions set, that page would redirect to the authentication page IF AND ONLY IF the current user was logged in as a guest. After successful login, the page would be accessed. Otherwise, an oops would be displayed.

-- TedPavlic - 22 Jul 2003

Apologies for the length of this response, but an important point is being missed.

The current discussion treats everything to do with athentication, authorisation, and accounting (so called triple A) as one single thing under the single heading "authentication". Any major system recognises that these are 3 intertwined but largely independent aspects of policy in a system:

  • Authentication - confirmation of identity for a request.
  • Authorisation - what abilities is the authenticated or not authenticated person granted? eg Is this person:
    • Allowed to access the content
    • Change the content
    • View the content
    • Allowed to know content even exists ? (This is essentially authorisation on the directory tree)
  • Accounting - tracking who did what.

Twiki is extremely good in the general case at accounting - as long as actions are authenticated. After all, you're able to get down to single letter changes and see a full audit trail for text pages. This even happens if the user is only authenticated as a TWikiGuest. Currently TWiki's accounting includes:

  • A central log is created
  • A specific log of changes is created ( .changes )
  • RCS logs of changes including timestamp are created
Furthermore these points are open for inspection in an extremely simple manner. (page diffs, changes, mail notification etc)

For authentication TWiki has three possible modes:

  1. No authentication. (More specifically everyone authenticated as TWikiGuest)
  2. Authentication for some actions.
  3. Authentication for for all actions.

Currently authentication for item 2 relies on auth copies of the scripts.

For authorisation TWiki has at least the following modes:

  • No authorisation required
  • Authorisation required for appending content (eg comment plugin, email plugin usable by TWikiGuest)
  • Authorisation required for refactoring content
  • Authorisation required for viewing some content
  • Authorisation required for viewing all content

Note: all of these relate to issues regarding reading content or modification of content. As a result the majority of systems prefer to enforce authorisation in the filesystem - can the file be opened for writing, reading, appending, can we traverse down through the directory tree for access to be able to check permissions lower down through the tree. This is not exactly a new problem! smile

The problem you're hitting in general isn't an authentication problem: it's an authorisation problem.

To make user's lives easier you want to fail back gracefully from to allow authentication, and you want a nice easy way of doing that. On a secondary side, TWiki can also use authentication for personalisation of content rather than authorisation of actions. For this you need to have authentication available all the time. This is a very different issue. You can call this sessions, or anything you want, but that's what it boils down to.

Points of note:

  • You can have authentication for authorisation - this needs a high trust level
  • You can have authentication for personalisation - this needs a much lower trust level. (Indeed it requires no trust level)

Regarding the authentication issue, bear in mind that the majority case is that many people just don't bother with authentication with Wikis. (plain and simple fact) This makes authorisation simple. With TWiki, many people simply require authorisation for changing content. This means that Apache authentication works fine: it only happens where necesary for specific scripts for changing content.

The sticking point is that a minority of people now wish to have authentication for viewing for 2 reasons:

  1. Personalisation of content
  2. View restrictions.

1 can be dealt with fairly well using remote IP - however TWiki deals with proxies poorly in this regard at present. 2 However requires the view scripts to have a means of failing over gracefully - and being forced by the storage system to fail.

Given the solution to 1) can inherently be simpler than that for 2 if you use a simple solution for 1, then the result is that 2) will potentially have holes & problems. Combine*that with a backend ( TWiki::Store.pm ) that doesn't actually perform the required access checking in all the locations that access the stored data (eg getRevisionDiff ) and you leave the authorisation aspects being enforced in lots of locations where it shouldn't be. (Even viewauth's backend enforcement is IMO fudged - but fudged to my current satisfaction since I haven't fixed it wink )

As a result it's worth reiterating that if you simply focus on authentication, rather than authorisation you will still hit border/boundary cases that you really don't want to. Whether you have 1, 10, 100 front end scripts in place if you don't have authorisation of content resolved to your satisfaction then you will continue to hit "quirks" no matter what authentication scheme you use.

On a side note: ETags are designed to allow systems to determine if content has changed this can be anything from a revision number through a simple checksum to an MD5 hash. The idea was that this allowed clients, server farms and proxies to easily detect whether content had changed. Early implementations of Apache included the unix inode number in the Etag which basically invalidated the whole thing (unchanged content in a web server farm would have multiple differeing Etags). As a result many proxies highly mistrust content with etags - leaving the content relatively non-cacheable. (Some do interesting things like detect webserver and cache based on known brokenness of the webserver) The way Etags have been abused in the past is the reason they're essentially useless now, something I personally would not like to encourage. (Having worked in the large scale proxy caching field for over 4 years, before moving on to where I am now)

Regarding improving the doRememberRemoteUser setup to deal with proxies - this is on my todo list. Not for authorisation mind. (You can't rely on the Via header existing - you're more likely to get Client-IP or X-Forwarded-For)

Regarding this very minor point of using the approach I laid out to allow any script to authenticate :

 
"I see little difference between [auth script & sym links] except that in the auth script example Windows users are a little happier (does CygWin support symlinks? (that relates to BetterThan...))."
I agree with this - it is little different (This was partly my point - it doesn't resolve the authorisation aspects alone smile ). However it has the following advantages:
  • It is more Windows friendly - Windows does not have symlinks in the Unix sense AFAICT (I'm not a windows user so I might be wrong there). It seems that Cygwin does support symlinks, based on feedback from the TWikiUnixInstaller. (Though it looks like there is a high overhead for doing so)
  • It ensures that unlike symlinks that the authenticating version is always there.
  • It changes it so that rather than having a 1/2 dozen or so entries in the apache config that require authentication, which needs to be changed potentially if you add new code (eg plugins with scripts, new scripts) you only have one entry in your apache config.
  • It's essentially equivalent to your original request, but without the redirect. (And hence simpler to implement)

Oh and just a reminder: the majority of Wikis do not use authentication and authorisation at all.

By the way, DO WE REALLY NEED TO SHOUT ALL THE TIME AND CHANGE FONTS at every opportunity ? wink

-- MichaelSparks - 22 Jul 2003

"X-Forwarded-for" is what I meant. (DOH!) While parsing it properly it will improve things a bit, it still won't do anything for an anonymous proxy or a NAT router. You need a marker set at the browser's machine. Cookies and URL munging are the traditional ways to handle that.

Extending apache authorization with mod_perl is actually quite easy. I will also point out that if you don't have the rights to use the necessary directives in the .htaccess file for the custom mod_perl stuff (perlAuthHandler perlAccessHandler, perlAuthzHandler, etc.), chances are not good you don't have the necessary rights to get TWiki authorizations working in their current form.

You know what? The heck with mod_perl. Here, this is how you get apache to pass the username in the header to the view script if its set without a mandatory logon:

SetEnvIf Authorization "^$" anon
<Files "view">
    satisfy any
    require valid-user
    Order Deny,Allow
    Deny from all
    Allow from env=anon
</Files>

This is how to get apache to redirect to another page when authorization is required without the ugly menu:

ErrorDocument 401 http://yourdomain.com/my401error.cgi

(full "http://" required to supress apache "WWW-Authenticate" cycle).

I've always felt the username was the way to track the sessions. Store the user-specific information in the user's UserName topic - No cookies, no URL munging, no tricks, no cron cleanup. No fuss, no muss. If the user wishes to remain anonymous, then they won't get user-specific output/tracking.

The only thing left is tracking a session across beyond when a user closes the window. That's what a cookie is traditionally used for. As long as TWiki only produces a "Set-Cookie" http header at a very specific spot (on logon only), caching remains, for the most part, untouched for the rest of the pages because a cookie is not sent blindly. Proxies don't have too much problems caching output as long as there is no cookie in the response. But, the browser will forward the cookie matching the domain.

-- TomKagan - 22 Jul 2003

> Proxies don't have too much problems caching output as long as there is no cookie in the response.

Or in the request...

Proxies are aware that the majority of servers that vary content based on cookies sent from clients will not send a Vary: Cookie header with the response. (They're required to do this) Given this is a common case many proxies will not cache any response to a request that contains a cookie - or at least not serve any cached responsed to anyone who does not share that cookie. Set-Cookie essentially forces the response to be uncacheable (the spec if wooley here - a client can cache it if it knows the intent of the application sending the cookie...). Theoretically simply sending a cookie back should not make the response uncacheable. In practice however it does.

My point regarding Client-IP, and X-Forwarded-For is for customisation-authentication, not for authorisation-authentication. (there are others like this, it isn't standardised - squid uses the latter, whereas some commercial proxies who solved the same problems at the same times use the former) Most triple-A approaches attack this by having levels of trust based on the level of authentication. For example students at an institution vs joe bloggs on the internet. You might allow IP level authentication for those students so they never have to login (eg elsevier) or you might require a full blown username/password/SSL setup based on a cryptocard.

With regard to making things pretty, I don't think high trust in the authentication is required wink Regarding access control to a page that controls access to a database system that contains personel records, then that's a different matter.

As a principle though, TWiki should not be basing it's Authentication schemes based on the features available in one web server (eg mod_perl) in just the same way the Authorisation schemes should not be just based on the filesystems TWiki runs on top of.

-- MichaelSparks - 22 Jul 2003

Proxies not caching responses on cookies sent to the server can also be handled relatively easily in TWiki's case. By setting the path field of the cookie to other than the root (e.g: "/TwikiLogon/DoubleRedirect" instead of "/"), the browser should only send the cookie to the server when that specific path and sub-paths in the URL are requested. Since the rest of the requests would not include the cookie, the proxies should cache the rest of the responses. Adding little "Cache-Control" magic should also up the odds for proxies to cache the pages requiring a logon, too - assuming TWiki avoids cookies and sticks with credentials in the HTTP "authorization" header.

-- TomKagan - 23 Jul 2003

I finally hit one of the problems people are talking about here. (doRememberRemoteUser being treated with too high a level of trust) I may look into this at some point. (Essentially without re-authenticating I gained access to pages which I shouldn't have had access to, and as a side effect no other user would've been asked either - due to going through a proxy)

It's clear to me that having seen this issue in practice that it's definitely authorisation issues that people are hitting, not authentication. (Though the authentication treating a weak authentication method as equivalent to a strong authentication method really doesn't help) Solving this would benefit Ted's authentication solutions as well.

-- MichaelSparks - 24 Jul 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatEXT auth r2 r1 manage 0.1 K 2003-07-22 - 10:12 UnknownUser Zeroed length. (see AuthenticatedModeDiscussion)
Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2008-08-25 - 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.