| Home | Gifts |
has an option to protect file attachments.
Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.
.htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.
You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.
Note: If you are restricting the entire Main web to TWikiGuest, you are required to add TWikiRegistrationAgent to ALLOWWEBCHANGE in your Main/WebPreferences. By doing so, new users are able to register without any errors.
none in configure) Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.
TWiki::LoginManager::TemplateLogin login manager (on the Security Settings pane).
there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent browsers from remembering usernames and passwords if you are concerned about public terminal usage.
Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.
You can create a custom version of the TWikiRegistration form by copying the topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user profile page by creating the Main.NewUserTemplate topic, which will then override the default.
REMOTE_USER environment variable, which the webserver passes to TWiki when you enable authentication in the webserver (as described in RFC 3875 - "The Common Gateway Interface v1.1").
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules, such as mod_authnz_ldap or mod_authn_dbd, you can just plug in directly to them.
The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.
TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).
The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.
Warning: Do not use the Apache htpasswd program with .htpasswd files generated by TWiki! htpasswd wipes out email addresses that TWiki plants in the info fields of this file.
TWiki::LoginManager::ApacheLogin login manager.
.htpasswd entries.
.htaccess file in the twiki/bin directory. There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what needs to be done. If you got it right, the browser should now ask for a login name and password when you click on Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support) At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade. Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
bin/logon script enables this. If you are using Apache Login, the bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. Once authenticated, it will redirect the user to the view URL for the page from which the logon script was linked.
and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers, it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
%SESSION_VARIABLE{ "varName" }% |
Read a session variable |
%SESSION_VARIABLE{ "varName" set="varValue" }% |
Set a session variable |
%SESSION_VARIABLE{ "varName" clear="" }% |
Clear a session variable |
%SESSION_VARIABLE{"AUTHUSER"}% - user ID, current value:
%SESSION_VARIABLE{"SESSION_REQUEST_NUMBER"}% - number of pages accessed by current user since login, current value:
pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.
PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a user profile page in the Main web.
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for exampleMain.WikiUsernameor%USERSWEB%.WikiUsername. This pointsWikiUsernameto the Main web, where user profile pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
TWiki/ChangePassword )
TWiki/ResetPassword )
TWiki/ChangeEmailAddress )
.htaccess
attack. Once a hacker has an SID they can pretend to be that user.
To help prevent these sorts of attacks, TWiki supports IP matching, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.
Session IDs are usually stored by TWiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So TWiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in TWiki pages to include the session ID in the URL.
The first method works well as long as IP addresses are unique to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method.
If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".
Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the ether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing:
wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting
i.e. pass in a user and password to a request from the command-line. However it doesn't let you log out.
Template Login degrades to url re-writing when you use a client like dillo that does not support cookies. However, you can log out and back in as a different user.
Finally, it would be really neat if someone was to work out how to use certificates to identify users.....
See TWiki:TWiki.SecuringTWikiSite for more information.
Related Topics: AdminDocumentationCategory, TWikiAccessControl, VarAUTHREALM, VarGET, VarLOGIN, VarLOGOUT, VarSESSIONID, VarSESSIONVAR, VarSESSIONVARIABLE, VarSET, TWiki:TWiki.TWikiUserAuthenticationSupplement, TWiki:TWiki.SecuringTWikiSite
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie, TWiki:Main.SvenDowideit
| Revision r28 - 2014-07-13 - 20:49:50 - TWikiContributor | Edit |