Loading...
 

Background

Often, you want to create a wiki that can only be seen by people who have an account on it. One way to do this of course, is to put the wiki site behind some sort of a firewall. But if it's not an option for you, there are two other ways of doing it.

Recipe 1: Setting permissions so that anonymous can't do much.

  • This recipe is not as safe as recipe 2, but it avoids an annoying problem with the latter, namely, sometimes with recipe 2, you can't login at all (see below for details).
  • The reason why recipe 1 is not as safe is that if you forget to set even one permission correctly, you may introduce a "window" which anonymous users can use to peak at part of your content. For example, if you activate the search module and give anonymous permissions to it, then they will be able to at least find out if a particular keyword produces hits on your site (and see the title and a short exerpt of those hits).


Recipe 2: "closing" the site for maintenance

  • This is the safest of the two recipes, in that it garantees that anonymous will see nothing more than a simple login form.
  • But I have found that with this recipe, there are occasionally problems where you can't login at all, and have to run tiki-instsall.php to restore things back to normal.
  • Also, there seems to be problems with validation of new users, because they can't access the validation URL without logging in, and they can't login before they have validated their account.


The two recipes are described in details below.

Recipe 1: Setting permissions so that anonymous can't do much.

Here are the steps:

  • Log on as a user with admin privileges
  • First, make sure all Anonymous permissions are unchecked
    • Admin > Permissions
    • You see a bunch of links like:
      • blogs
      • calendar
      • cms
      • etc...
    • Click on each of those links in turn, and make sure that none of the checkbox in the Anonymous column are checked.
    • Whenever you modify configuration of the site, make sure you never give Anonymous permission to anything.
  • Next, make sure Anonymous does not have permission to any of the modules, other than the Loginbox and the Logo
    • Admin > Modules > Assigned Modules > No Tabs
    • If any module is assigned to Anonymous, click on the pen icon on that row, to change the permissions.


Note that self-registration is not possible with this approach, unless you want to allow people to register without email validation (probably not a good idea). The reason is that people cannot access the URL for email validation until they have been validated (chicken and egg kind of thing).

So it's best to disable self-registration and email validation:

  • Admin > Login > General Preferences
  • Unckeck Users can register


From there on, you'll have to manually invite people who should have access to the site:

  • Admin > Users
  • Add a new yser
  • Probably best to check User must change password at next login.



Recipe 2: "closing" the site for maintenance

WARNING: I have found that with this recipe, there are occasionally problems where you can't login at all! See the section below about Can't login at all
.

Here are the steps:

  • Log on as a user with admin privileges
  • Admin > Admin Home > Security > Site access tab
  • Check Close site (except for those with permission)
  • In Message to display, Enter a message like: "This site is only visible to users with an account. If you need an account, email joe.bloe at somewhere.com"
  • Click on Save preferences button at the bottom of the page.


By default, Admin group has permission tiki_p_access_closed_site enabled. But unless you want to give all users on the site Admin privileges (probably not a good idea), you should probably grant tiki_p_access_closed_site to a more restricted group of users.

If your registration procedure is designed in such a way that people can't register without being vetted by an admin, then you can simply set this permission on Anonymous. However, if anybody can register without being vetted by an admin, then you probably need to create another group, say, TrustedUsers, and grant tiki_p_access_closed_site to that group.

To grant tiki_p_access_closed_site permission to a group:

  • Log on as a user with admin privileges
  • Admin > Admin Home
  • Groups (link at bottom of page)
  • In the row for the group you want to give the permsision to, click on the key icon
  • In Find, closed and hit Find button.
  • Check the tiki_p_access_closed_site item, then click on the Update button.


From then on, anyone who does not have permission tiki_p_access_closed_site, will not be able to acess the site, and will only see a login screen. Users who want an account will email the admin whose address is specified in the closed site message. When that admin receives a request from a user, he can create an account for him as follows:

  • Log on as a user with admin privileges
  • Admin Home
  • Users link (bottom of page)
  • Add new user tab
  • Enter a new user name, generate a password, and enter the email of the person who asked for an account.

Can't login at all

For reasons that I don't understand, if you use this recipe, you may occasionally run into trouble where the login screen stops recognizing legal users, and it looks like nobody, including admins, can access the site anymore.

This seems to happen on servers where there are more than one tiki sites running. Also, it seems to happen more frequently (but not exclusively) after upgrades to the tiki software.

But fear not! You can fix this problem by running tiki-install.php, and upgrading the database.

Problem validating new users

Another problem which I have occasionally experienced with this recipe is that new users can't validate their account. That's because they can't access the validation URL they received by email without logging in, and they can't login before they have validated their account.

See also


Page last modified on Monday 23 April, 2012 12:38:02 GMT-0000

doc.tiki.org

Get Started

Admin Guide User Guide Bootstrap in Tiki

Keywords

Keywords serve as "hubs" for navigation within the Tiki documentation. They correspond to development keywords (bug reports and feature requests):

Accessibility (WAI and 508)
Accounting
Articles and Submissions
Backlinks
Banners
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Link Cache
Calendar
Category
Chat
Clean URLs
Comments
Communication Center
Compression (gzip)
Contacts (Address Book)
Contact us
Content Templates
Contribution
Cookie
Copyright
Credit
Custom Home and Group Home Page
Date and Time
Debugger Console
Directory of hyperlinks
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
Draw
Dynamic Content
Dynamic Variable
External Authentication
FAQ
Featured links
File Gallery
Forum
Friendship Network (Community)
Gmap Google maps
Groups
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
Kaltura video management
Karma
Live Support
Login
Logs (system & action)
Look and Feel
Mail-in
Map with Mapserver
Menu
Meta Tags
Mobile Tiki and Voice Tiki
Mods
Module
MultiTiki
MyTiki
Newsletter
Notepad
Payment
Performance Speed / Load
Permissions
Platform independence (Linux-Apache, Windows/IIS, Mac, BSD)
Polls
Profiles
Profile Manager
Report
Toolbar
Quiz
Rating
Feeds
Score
Search engine optimization
Search
Search and Replace
Security
Semantic links
Shadowbox
Shadow Layers
Share
Shopping cart
Shoutbox
Slideshow
Smiley
Social Networks
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Stats
Surveys
Tags
Task
Tell a Friend, alert + Social Bookmarking
TikiTests
Theme CSS & Smarty
Trackers
Transitions
TRIM
User Administration including registration and banning
User Files
User Menu
Watch
WebDAV
Webmail
Web Services
Wiki History, page rename, etc
Wiki Syntax
Wiki structure (book and table of content)
Workspace
WSOD
WYSIWYCA
WYSIWYG
XMLRPC

Tiki Newsletter

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki