Reducing spam in Moodle: Difference between revisions
From MoodleDocs
Abel Camacho (talk | contribs) No edit summary |
Marc Grober (talk | contribs) No edit summary |
||
| Line 3: | Line 3: | ||
* Leave "Force users to login for profiles" enabled in ''Administration > Security > [[Site policies]]'' to keep anonymous visitors and search engines away from user profiles. | * Leave "Force users to login for profiles" enabled in ''Administration > Security > [[Site policies]]'' to keep anonymous visitors and search engines away from user profiles. | ||
* Leave self registration disabled in ''Administration > Users > Authentication > [[Manage authentication]]'' common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it. | * Leave self registration disabled in ''Administration > Users > Authentication > [[Manage authentication]]'' common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it. | ||
* If [[Email-based self-registration]] is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). | * If [[Email-based self-registration]] is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). However, please realize that a) CAPTCHA will not foil manual attempts and there are documented CAPTCHA exploits now documented. In other words, CAPTCHA is NOT an ANSWER. It is only one more obstacle you might interpose between your site and neer-do-wells in the hope of limiting exploitation. | ||
* If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in ''Administration > Security > [[Site policies]]'' (in Moodle 1.8.6 or 1.9.2 onwards). | * If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in ''Administration > Security > [[Site policies]]'' (in Moodle 1.8.6 or 1.9.2 onwards). | ||
* Consider the [[Risks|spam risks]] involved in allowing certain capabilities, such as [[Capabilities/mod/forum:replypost| replying to forum posts]], for visitor accounts. | * Consider the [[Risks|spam risks]] involved in allowing certain capabilities, such as [[Capabilities/mod/forum:replypost| replying to forum posts]], for visitor accounts. | ||
Revision as of 21:18, 1 November 2008
Here are some suggestions for reducing the risk of spam in Moodle:
- Leave "Force users to login for profiles" enabled in Administration > Security > Site policies to keep anonymous visitors and search engines away from user profiles.
- Leave self registration disabled in Administration > Users > Authentication > Manage authentication common settings, or limit self registration to particular email domains with the allowed email domains setting, or only enable self registration for a short period of time to allow users to create accounts, and then later disable it.
- If Email-based self-registration is used for self registration, add spam protection to the new account form by enabling reCAPTCHA (in Moodle 1.9.1 onwards). However, please realize that a) CAPTCHA will not foil manual attempts and there are documented CAPTCHA exploits now documented. In other words, CAPTCHA is NOT an ANSWER. It is only one more obstacle you might interpose between your site and neer-do-wells in the hope of limiting exploitation.
- If Email-based self-registration is used for self registration, leave "Email change confirmation" enabled in Administration > Security > Site policies (in Moodle 1.8.6 or 1.9.2 onwards).
- Consider the spam risks involved in allowing certain capabilities, such as replying to forum posts, for visitor accounts.
