This question about Authentication or Authorisation: Answered

Require authentication for every access


The 'Overview' section at 'System/UserAuthentication' mentions that you can setup Foswiki to require authentication for every access and 'Logons via bin/logon' section mentions about the 'bin/logon' script but I couldn't figure out how to achieve what I want.

I wish to setup Foswiki for internal access but the wiki is accessible from the web. So I wish show the login page as the home page. Users have to login before they can view/edit/create topics. Can anyone guide me or provide hints on how to achieve this? For you info, I'm not a Perl programmer.


-- TzeHoweYong - 21 Apr 2009

Go to your site home page, click in login, copy the url in the address bar and redirect users to that address. It would be something like this:
If it is a dedicated server you can redirect users by using this index.html to be the default page in your site.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" >
    <title>Your site title</title>
     <META HTTP-EQUIV="REFRESH" CONTENT="0;URL=http://your-web-address/foswiki/bin/login/Main/WebHome?origurl=/foswiki/bin/view/Main/WebHome">

-- EnriqueCadalso - 21 Apr 2009

I'm not sure that Enrique's solution is enough: that protects the root of the web server only (index.html). Someone could easily get to another page without authenticating by simply typing the URL of some standard content shipped with Foswiki (WebTopicList would be a good place to start!).

> Users have to login before they can view/edit/create topics

Edit and create (i.e., save) already require authentication, by virtue of the following Apache directive:

     <FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
         require valid-user
Add 'view' to that list, and I think you're done.

BTW, there is a '/bin/viewauth' program which can force authentication before viewing a topic. But it's identical to '/bin/view'! The only difference is that the former matches ".*auth" in that Apache directive.

-- SeanMorgan - 22 Apr 2009

Sean's solution seems to work for Apache login. If I switch back to using template login with the Apache directive, users need to perform double login. Is there any solution if I were to use template login? Perhaps simple patch to say 'if no user authentication, re-direct to login page'?

-- TzeHoweYong - 22 Apr 2009

In configure there is an {AuthScripts} setting where you can define the scripts that need auth in TemplateLogin without needing the extra Apache directive.

-- CrawfordCurrie - 22 Apr 2009

Yeap, I did not get the idea of what was wanted. I think that denying view access to WikiGuest will also do the work. Add this to every WebPreference topic in every web. Users will be forced to log on before viewing any page. (I am not sure if you have to add also a DENYWEBCHANGE to WikiGuest but it wont hurt if you do.)
      * Set DENYWEBVIEW = %USERSWEB%.WikiGuest
-- EnriqueCadalso - 22 Apr 2009

FYI, the /bin/viewauth script is not identical to /bin/view. It differs in the name of the script (and the call passed via $ENV{FOSWIKI_ACTION}.

If you have server access, you can rename /bin/view to /bin/view_noauth and then link (with ln) or copy /bin/viewauth to /bin/view, you can get authentication required for view.

Or use bin/configure and add view to the list of scripts for the {AuthScripts} setting (under 'Security and Authentication').

-- VickiBrown - 13 Jun 2014

The correct answer is indeed to add the DENY to the guest user in the WebPreferences topic of all webs. That will cause Foswiki to require a login regardless apache or template login. If you really want to totally lock down view with no option to "open" individual topics to guests:
  • Add view to the AuthScripts list. Foswiki throws an Authentication exception for any request matching this list, when the user is not authenticated.
  • For ApacheAuth: Also add view to the FilesMatch (cgi) or LocationMatch (fastcgi) directive that requires a =ValidUser=
The (auth) version of the scripts exist so that foswiki has something to redirect-to that matches a FilesMatch or LocationMatch directive in apache in the event authentication is required. Copying viewauth to view is unnecessary, and indeed if you are using FastCGI / FCGID, the scripts are not used at all. The only script executed is the foswiki.fcgid script. If you check, the ENV{FOSWIKI_ACTION} is mapped to a SwitchBoard entry. The entry for viewauth is identical to the entry for view.

Copying viewauth to view simply changes the action to a value that matches viewauth in the AuthScripts list. Much easier to just add view to that list.

-- GeorgeClark - 13 Jun 2014

QuestionForm edit

Subject Authentication or Authorisation
Status Answered
Related Topics
Topic revision: r8 - 13 Jun 2014, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy