Item931: Correct and simplify the {AuthScripts} documentation in configure

{AuthScripts} documentation states:

Comma-separated list of scripts that require the user to authenticate. (...) With ApacheLogin, they will be redirected to the logon script (note login and logon; they are different scripts). This approach means that only the logon script needs to be specified as require valid-user when using Apache authentication.

So, the only script I'd need to protect is logon, but it doesn't work in practice. IIUC, the only purpose of logon script is this, otherwise it's a redundant copy of login.

-- GilmarSantosJr - 31 Jan 2009

Correct

-- CrawfordCurrie - 01 Feb 2009

as a bit of history, until very recently, the 2 were coded differently too - I got a bit bored of that, and coalesced the code. One of them should be protected using only {AuthScripts} (login), while the other should probably be protected using both {AuthScripts} and the web server based auth system. (so that if something goes wrong with the web server auth, your foswiki is still protected.

Given that, its possible that we can actually remove one - but doing so may well expose someone's foswiki to a security issue..?

I'm not entirely sure what to make of this Task - I can't see what is the proposed problem, and so can't think of a required solution

-- SvenDowideit - 01 Feb 2009

The problem here is that {AuthScripts} doc says that Foswiki redirects requests to them to logon, when ApacheLogin is in use, but it doesn't happen.

If I protect only logon script in apache config, then viewauth doesn't force me to login, for example.

-- GilmarSantosJr - 02 Feb 2009

AHA. ok, so the bug is that when a script is in {AuthScripts}, foswiki redirects to viewauth, when really it should redirect to logon - as viewauth is pretty redundant now. makes alot of sense - course at this point, updating docco to say you shoudl also require valid-user for viewauth, rest, rdiff, etc, etc may be easier (not ).

related point - can I set {AuthScripts} = * ??

-- SvenDowideit - 02 Feb 2009

It is the documentation in configure that is wrong. The logon script with ApacheLogin is used for manual login. Ie for when you click the Login link in the left bar.

When you view a topic that you are not allowed to view Foswiki redirects to viewauth.

With ApacheLogin view should not be protected by the webserver and viewauth must be.

If you protect view and use for example mod_ldap for authentication it means the ldap server is used for every page view instead of using the session cookie. At Motorola this is seen as a 2-4 second delay on each page view. Reason is that the corporate ldap server is somewhere 6000 km away and already overloaded.

It is extremely important that the view -> viewauth redirect is kept intact. It works well.

Another important point is that because this is how TWiki and now Foswiki has worked for quite many years and because the URL people have in the browser right after authentication is the viewauth version, quite many Intranet links have been made with the viewauth and quite many emails and word documents and excel sheets have been made and circulated with viewauth links. This is not a problem is practical life but if some punk removes viewauth from Foswiki it will be a disaster of broken URLs pointing from everywhere on the corporate intranets to the Foswiki.

And additionally some plugins redirects to viewauth. For example ChecklistTablePlugin, EditTablePlugin, PreferencesPlugin..

viewauth cannot be removed. The funny thing is that the 'logon' also results in redirecting to viewauth. So it is more logon that is redundant it seems.

So it is the documentation that is wrong.

In our normal setup for ApacheLogin we list today

<FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
    require valid-user
</FilesMatch>

Maybe we need to review this list. It is not that long ago rest was added on a bug item as a security issue for not being. So watch out. The risk of breaking something or creating a security issue is huge. What is important to note is that 'view' is not in the list and that is correct and important for performance when using ApacheLogin.

The action needed for 1.0.1 is correction of the text in configure. In my view most of that text is plain wrong. As I see it it is an expert setting noone should ever need to alter unless that write a plugin with a bin script that needs authentication in TemplateLogin. I suggest we change the text to max 3 lines that explains that these are the bin scripts that get authenticated and that you can add your own bin scripts if you write an extension that needs that. And nothing more.

-- KennethLavrsen - 02 Feb 2009

Thanks for the detailed feedback, Kenneth!

I see no big deal (conceptually) in correcting ApacheLogin to behave like the documentation states. Suppose we have a setup where only logon is protected by Require valid-user. Nothing more. Then someone is not authenticated and follows a viewauth link (or edit or any other {AuthScritps}), then ApacheLogin will not have a logged in user nor credentials. In such a case there would be a redirect to logon (the same way that happens with TemplateLogin), then apache would prompt for the credentials. Nothing breaks.

I see two advantages if this works:

• I don't have to keep the same setting in two different places (apache config and {AuthScripts} setting)
• If I want to protect {AuthScripts} like they were always protected, things keep working.

As Sven pointed out in the IRC: foswiki should behave well in both situations. For instance: I setup my test apache to require authentication only to logon script, then I tried to edit a topic. I got a permission error, since WikiGuest didn't have write permission. If ApacheLogin worked like the documentation states, I would be redirected to logon, then I would have chance to log in.

-- GilmarSantosJr - 02 Feb 2009

Historically logon and login were different scripts; these days they have different names, but identical function. Surely we only need one script?

-- CrawfordCurrie - 02 Feb 2009

There are sites I've heard of that use bother apache and template auth - After the last auth pain, I'd be very wary of removing the 2 options.

and then there are other sites that do protect all the scripts including view using apache auth - because they are totally invite only private.

mind you, I'm thinking more that we can do away with viewauth - as that can be replaced with logon :).

frustrating how these auth things require more text to describe their function than they do code.

-- SvenDowideit - 08 Feb 2009

I say again, If we remove viewauth 100s of links from intranet pages and I don't know how many emails will no longer work. People often logged into T*iki/Foswiki, copied the URL from the browser and sent it in an email or used it to link from some other site. I have seen very very often that these URLs was the viewauth version.

So please do not remove viewauth just like that.

-- KennethLavrsen - 08 Feb 2009

Docu is now updated.

-- KennethLavrsen - 25 Apr 2009