From 090743bdbaf4866da57c6c54b03c398477903168 Mon Sep 17 00:00:00 2001 From: Dries Buytaert Date: Mon, 21 Jun 2004 20:05:37 +0000 Subject: - Patch #8670 by asimmonds: more spelling fixes. --- modules/user/user.module | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'modules/user/user.module') diff --git a/modules/user/user.module b/modules/user/user.module index 4165597b2..ba6f4239e 100644 --- a/modules/user/user.module +++ b/modules/user/user.module @@ -1747,7 +1747,7 @@ function user_help($section) {

Drupal offers a powerful access system that allows users to register, login, logout, maintain user profiles, etc. By using roles you can setup fine grained permissions allowing each role to do only what you want them to. Each user is assigned to one or more roles. By default there are two roles \"anonymous\" - a user who has not logged in, and \"authorized\" a user who has signed up and who has been authorized. As anonymous users, participants suffer numerous disadvantages, for example they cannot sign their names to nodes, and their moderated posts beginning at a lower score.

In contrast, those with a user account can use their own name or handle and are granted various privileges: the most important is probably the ability to moderate new submissions, to rate comments, and to fine-tune the site to their personal liking, with saved personal settings. Drupal themes make fine tuning quite a pleasure.

Registered users need to authenticate by supplying either a local username and password, or a remote username and password such as a Jabber ID, DelphiForums ID, or one from a Drupal powered website. See the distributed authentication help for more information on this innovative feature. - The local username and password, hashed with Message Digest 5 (MD5), are stored in your database. When you enter a password it is also hashed with MD5 and compaired with what is in the database. If the hashes match, the username and password are correct. Once a user authenticated session is started, and until that session is over, the user won't have to re-authenticate. To keep track of the individual sessions, Drupal relies on PHP sessions. A visitor accessing your website is assigned an unique ID, the so-called session ID, which is stored in a cookie. For security's sake, the cookie does not contain personal information but acts as a key to retrieve the information stored on your server. When a visitor accesses your site, Drupal will check whether a specific session ID has been sent with the request. If this is the case, the prior saved environment is recreated.

+ The local username and password, hashed with Message Digest 5 (MD5), are stored in your database. When you enter a password it is also hashed with MD5 and compared with what is in the database. If the hashes match, the username and password are correct. Once a user authenticated session is started, and until that session is over, the user won't have to re-authenticate. To keep track of the individual sessions, Drupal relies on PHP sessions. A visitor accessing your website is assigned an unique ID, the so-called session ID, which is stored in a cookie. For security's sake, the cookie does not contain personal information but acts as a key to retrieve the information stored on your server. When a visitor accesses your site, Drupal will check whether a specific session ID has been sent with the request. If this is the case, the prior saved environment is recreated.

User preferences and profiles

Each Drupal user has a profile, and a set of preferences which may be edited by clicking on the \"my account\" link. Of course, a user must be logged into reach those pages. There, users will find a page for changing their preferred time zone, language, username, e-mail address, password, theme, signature, and distributed authentication names. Changes made here take effect immediately. Also, administrators may make profile and preferences changes in account administration on behalf of their users.

Distributed authentication

-- cgit v1.2.3