From f1dfe0639a76dc8ba1fe33cddd72d824c83c9fd4 Mon Sep 17 00:00:00 2001 From: Dries Buytaert Date: Wed, 21 Jan 2004 17:26:59 +0000 Subject: - Bug 5285: fixed broken URLs in user module. Patch by Stefan. --- modules/user.module | 18 +++++++++--------- modules/user/user.module | 18 +++++++++--------- 2 files changed, 18 insertions(+), 18 deletions(-) (limited to 'modules') diff --git a/modules/user.module b/modules/user.module index 82d766e00..4b15e2705 100644 --- a/modules/user.module +++ b/modules/user.module @@ -456,7 +456,7 @@ function user_link($type) { if (user_access("administer users")) { menu("admin/user", t("accounts"), "user_admin", 2); menu("admin/user/create", t("new user"), "user_admin", 1); - menu("admin/user/access", t("access rules"), NULL, 3); + menu("admin/user/access", t("access rules"), "user_admin", 3); menu("admin/user/access/mail", t("e-mail rules"), "user_admin"); menu("admin/user/access/user", t("name rules"), "user_admin"); menu("admin/user/role", t("roles"), "user_admin", 4); @@ -1630,26 +1630,26 @@ function user_help($section = "admin/help#user") { case 'admin/help#user': // Start of user_help_admin - $output .= "

Introduction

Drupal offers a powerful access system that allows users to register, login, logout, maintain user profiles, etc. By using \"%user-role\" you can setup fine grained %user-permission allowing each role to do only what you want them to. Each user is assigned to a role. 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.

"; + $output .= "

Introduction

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 a role. 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.

"; $output .= "

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.

"; - $output .= "

Registered users need to authenticate by supplying either a local username and password, or a remote username and password such as a %jabber, %delphiforums, or one from another %drupal website. See %da-auth for more information on this innovative feature."; - $output .= "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-sess. 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.

"; - $output .= "

User preferences and profiles

Each Drupal user has a profile, and a set of preferences which may be edited by clicking on the %user-prefs 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 %da-auth names. Changes made here take effect immediately. Also, administrators may make profile and preferences changes in %admin-user on behalf of their users.

"; - $output .= "

Module developers are provided several hooks for adding custom fields to the user view/edit pages. These hooks are described in the Developer section of the %da-devel. For an example, see the jabber_user() function in /modules/jabber.module.

"; + $output .= "

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."; + $output .= "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.

"; + $output .= "

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.

"; + $output .= "

Module developers are provided several hooks for adding custom fields to the user view/edit pages. These hooks are described in the Developer section of the developers guide. For an example, see the jabber_user() function in /modules/jabber.module.

"; //end of user_help_admin //start of user_help_admin_da $output .= "

Distributed authentication

"; $output .= "

One of the more tedious moments in visiting a new website is filling out the registration form. The reg form provides helpful information to the website owner, but not much value for the user. The value for the end user is usually the ability to post a messages or receive personalized news, etc. Distributed authentication (DA) gives the user what they want without having to fill out the reg form. Removing this obstacle yields more registered and active users for the website.

"; - $output .= "

DA enables a new user to input a username and password into the login box and immediately be recognized, even if that user never registered on your site. This works because Drupal knows how to communicate with external registration databases. For example, lets say that your new user 'Joe' is already a registered member of Delphi Forums. If your Drupal has the delphi module installed, then Drupal will inform Joe on the registration and login screens that he may login with his Delphi ID instead of registering with your Drupal instance. Joe likes that idea, and logs in with a username of joe@remote.delphiforums.com and his usual Delphi password. Drupal then communicates with remote.delphiforums.com (usually using %xml, %http-post, or %soap) behind the scenes and asks "is this password for username=joe?" If Delphi replies yes, then Drupal will create a new local account for joe and log joe into it. Joe may keep on logging into your Drupal instance in the same manner, and he will be logged into the same joe@remote.delphiforums.com account.

"; + $output .= "

DA enables a new user to input a username and password into the login box and immediately be recognized, even if that user never registered on your site. This works because Drupal knows how to communicate with external registration databases. For example, lets say that your new user 'Joe' is already a registered member of Delphi Forums. If your Drupal has the delphi module installed, then Drupal will inform Joe on the registration and login screens that he may login with his Delphi ID instead of registering with your Drupal instance. Joe likes that idea, and logs in with a username of joe@remote.delphiforums.com and his usual Delphi password. Drupal then communicates with remote.delphiforums.com (usually using %xml, %http-post, or %soap) behind the scenes and asks "is this password for username=joe?" If Delphi replies yes, then Drupal will create a new local account for joe and log joe into it. Joe may keep on logging into your Drupal instance in the same manner, and he will be logged into the same joe@remote.delphiforums.com account.

"; $output .= "

One key element of DA is the 'authmap' table, which maps a user's authname (e.g. joe@remote.delphiforums.com) to his local UID (i.e. user identification number). This map is checked whenever a user successfully logs into an external authentication source. Once Drupal knows that the current user is definately joe@remote.delphiforums.com (because Delphi says so), he looks up Joe's UID and logs Joe into that account.

"; - $output .= "

To disable distributed authentication, simply %dis-module or remove all DA modules. For a virgin install, that means removing/disabling the jabber module and the drupal module.

"; + $output .= "

To disable distributed authentication, simply disable or remove all DA modules. For a virgin install, that means removing/disabling the jabber module and the drupal module.

"; $output .= "

Drupal is setup so that it is very easy to add support for any external authentication source. You currently have the following authentication modules installed ...

"; $output .= "%module-list"; // end of user_help_admin_da // start of user_help_devel_da - $output .= "

Writing distributed authentication modules

Drupal is specifically architected to enable easy authoring of new authentication modules. I'll deconstruct the %blogger authentication module, and hopefully provide all the details you'll need to write your own auth module. If you want to download the full text of this module, visit the %blogger-source in the %contrib-cvs.

"; + $output .= "

Writing distributed authentication modules

Drupal is specifically architected to enable easy authoring of new authentication modules. I'll deconstruct the blogger authentication module, and hopefully provide all the details you'll need to write your own auth module. If you want to download the full text of this module, visit the module in the contributions repository.

"; $output .= "

Code review

"; $output .= "
function blogger_auth(\$name, \$pass, \$server) {
   // user did not present a Blogger ID so don't bother trying.
diff --git a/modules/user/user.module b/modules/user/user.module
index 82d766e00..4b15e2705 100644
--- a/modules/user/user.module
+++ b/modules/user/user.module
@@ -456,7 +456,7 @@ function user_link($type) {
     if (user_access("administer users")) {
       menu("admin/user", t("accounts"), "user_admin", 2);
       menu("admin/user/create", t("new user"), "user_admin", 1);
-      menu("admin/user/access", t("access rules"), NULL, 3);
+      menu("admin/user/access", t("access rules"), "user_admin", 3);
       menu("admin/user/access/mail", t("e-mail rules"), "user_admin");
       menu("admin/user/access/user", t("name rules"), "user_admin");
       menu("admin/user/role", t("roles"), "user_admin", 4);
@@ -1630,26 +1630,26 @@ function user_help($section = "admin/help#user") {
     case 'admin/help#user':
 
       // Start of user_help_admin
-      $output .= "
Introduction
Drupal offers a powerful access system that allows users to register, login, logout, maintain user profiles, etc. By using \"%user-role\" you can setup fine grained %user-permission allowing each role to do only what you want them to. Each user is assigned to a role. 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.
";
+      $output .= "
Introduction
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 a role. 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.
";
       $output .= "
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.
";
-      $output .= "
Registered users need to authenticate by supplying either a local username and password, or a remote username and password such as a %jabber, %delphiforums, or one from another %drupal website. See %da-auth for more information on this innovative feature.";
-      $output .= "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-sess. 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.
";
-      $output .= "
User preferences and profiles
Each Drupal user has a profile, and a set of preferences which may be edited by clicking on the %user-prefs 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 %da-auth names. Changes made here take effect immediately. Also, administrators may make profile and preferences changes in %admin-user on behalf of their users.
";
-      $output .= "
Module developers are provided several hooks for adding custom fields to the user view/edit pages. These hooks are described in the Developer section of the %da-devel. For an example, see the jabber_user() function in /modules/jabber.module.
";
+      $output .= "
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.";
+      $output .= "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.
";
+      $output .= "
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.
";
+      $output .= "
Module developers are provided several hooks for adding custom fields to the user view/edit pages. These hooks are described in the Developer section of the developers guide. For an example, see the jabber_user() function in /modules/jabber.module.
";
       //end of user_help_admin
 
       //start of user_help_admin_da
       $output .= "
Distributed authentication
";
       $output .= "
One of the more tedious moments in visiting a new website is filling out the registration form. The reg form provides helpful information to the website owner, but not much value for the user. The value for the end user is usually the ability to post a messages or receive personalized news, etc. Distributed authentication (DA) gives the user what they want without having to fill out the reg form. Removing this obstacle yields more registered and active users for the website.
";
-      $output .= "
DA enables a new user to input a username and password into the login box and immediately be recognized, even if that user never registered on your site. This works because Drupal knows how to communicate with external registration databases. For example, lets say that your new user 'Joe' is already a registered member of Delphi Forums. If your Drupal has the delphi module installed, then Drupal will inform Joe on the registration and login screens that he may login with his Delphi ID instead of registering with your Drupal instance. Joe likes that idea, and logs in with a username of joe@remote.delphiforums.com and his usual Delphi password. Drupal then communicates with remote.delphiforums.com (usually using %xml, %http-post, or %soap) behind the scenes and asks "is this password for username=joe?" If Delphi replies yes, then Drupal will create a new local account for joe and log joe into it. Joe may keep on logging into your Drupal instance in the same manner, and he will be logged into the same joe@remote.delphiforums.com account.
";
+      $output .= "
DA enables a new user to input a username and password into the login box and immediately be recognized, even if that user never registered on your site. This works because Drupal knows how to communicate with external registration databases. For example, lets say that your new user 'Joe' is already a registered member of Delphi Forums. If your Drupal has the delphi module installed, then Drupal will inform Joe on the registration and login screens that he may login with his Delphi ID instead of registering with your Drupal instance. Joe likes that idea, and logs in with a username of joe@remote.delphiforums.com and his usual Delphi password. Drupal then communicates with remote.delphiforums.com (usually using %xml, %http-post, or %soap) behind the scenes and asks "is this password for username=joe?" If Delphi replies yes, then Drupal will create a new local account for joe and log joe into it. Joe may keep on logging into your Drupal instance in the same manner, and he will be logged into the same joe@remote.delphiforums.com account.
";
       $output .= "
One key element of DA is the 'authmap' table, which maps a user's authname (e.g. joe@remote.delphiforums.com) to his local UID (i.e. user identification number). This map is checked whenever a user successfully logs into an external authentication source. Once Drupal knows that the current user is definately joe@remote.delphiforums.com (because Delphi says so), he looks up Joe's UID and logs Joe into that account.
";
-      $output .= "
To disable distributed authentication, simply %dis-module or remove all DA modules. For a virgin install, that means removing/disabling the jabber module and the drupal module.
";
+      $output .= "
To disable distributed authentication, simply disable or remove all DA modules. For a virgin install, that means removing/disabling the jabber module and the drupal module.
";
       $output .= "
Drupal is setup so that it is very easy to add support for any external authentication source. You currently have the following authentication modules installed ...
";
       $output .= "%module-list";
       // end of user_help_admin_da
 
       // start of user_help_devel_da
-      $output .= "
Writing distributed authentication modules
Drupal is specifically architected to enable easy authoring of new authentication modules. I'll deconstruct the %blogger authentication module, and hopefully provide all the details you'll need to write your own auth module. If you want to download the full text of this module, visit the %blogger-source in the %contrib-cvs.
";
+      $output .= "
Writing distributed authentication modules
Drupal is specifically architected to enable easy authoring of new authentication modules. I'll deconstruct the blogger authentication module, and hopefully provide all the details you'll need to write your own auth module. If you want to download the full text of this module, visit the module in the contributions repository.
";
       $output .= "
Code review
";
       $output .= "
function blogger_auth(\$name, \$pass, \$server) {
   // user did not present a Blogger ID so don't bother trying.
-- 
cgit v1.2.3