View source
<p>The <strong>Anonymous Publishing CL</strong> module is part of
the <strong><a href="https://drupal.org/project/anonymous_publishing"
title="project page">Anonymous Publishing</a></strong> project.</p>
<p>It lets users publish content without first registering an account
at the site, provided they supply a vaild email-address and click on
an activation link sent them in a verification email (some call this
the “craigslist model”).</p>
<h2>Configuration</h2>
<p>To access the <strong>Anonymous Publishing CL</strong>
administration form, you need to be granted the right to administer
anonymous publishing.</p>
<p>After installing and activating the module navigate to: <span class="nav">Configuration » People » Anonymous publishing CL</span>.</p>
<p>There are seven tabs:</p>
<ol>
<li>Main settings: All the main options for this module.</li>
<li>Message templates: Customize verificaton email sent out.</li>
<li>Moderation: Moderate anonymously published content.</li>
<li>Verified: Block (and unblock) verified email-addresses.</li>
<li>Unverified: Ban unverified users' IP addresses.</li>
<li>Spambots: Ban reported spambots' IP addresses.</li>
<li>Privacy: Privacy enhancing settings.</li>
</ol>
<h3>Main settings</h3>
<p>You first need to select the content type (or types) that you will
allow anonymous users to post. You may also enable anonymous
publishing for comments.</p>
<p>If you want to allow users that are not logged in to create
content, you must also give permission for the anonymous user to
create content. This is done by navigating to
<span class="nav">Configuration » People » Permissions</span>.</p>
<p>The rest of the settings on the settings page will only have an
effect on the type or types (including comments) selected here.</p>
<p>Here is a brief description of the options:</p>
<ul>
<li>Allow self-activation.<br />
If you check this option, content from anonymous publishers that has
not been previously validated will be automatically published when the
anonymous publisher verifies the email. If you leave this un-checked,
content from un-validated anonymous publishers will be flagged as
verified when the user verify the email-address, but it will not be
published until approved by a administrator. The setting has no effect
if the email-address is already validated. (See description of the
“Moderation” panel below for details about how activation works.)</li>
<li>Skip comment approval.<br />
This is greyed out, as this setting is managed by the Drupal core
comment module. Go to <span class="nav">Configuration » People » Permissions</span> to
set it. The core “Skip comment approval” setting retains it standard
meaning and its status is only included in this panel for information
purposes (previous setting). Note that if you allow self-activation,
but don't also check “Skip comment approval”, self-activated comments
will not be published when the user activates. They will just be
flagged as verified and not be published until they are approved by a
moderator. To avoid confusion, make sure this setting is in-sync with
the setting Allow self-activation.</li>
<li>Send email to the administrator when anonymous content is created.<br />
Checking this will automatically send an email to the administrator
email address whenever anonymous content is created. You may use this
to make sure the administrator becomes aware of possible problems
(such as spam), or to speed up the moderation process (if you do not
allow self-activation).</li>
<li>Use IP-address for blocking.<br />
By default, the “blocking” box only applies to the email used for
authentication. The module records the IP-address used to
authenticate, but this normally only used for flood control
purposes. When this option is set, the module will also block the
corresponding IP-address. Note that setting this option may result in
false positives (as one IP-address may be shared between several users
over time), so use this option with caution.</li>
<li>Allow registered emails to be used for anonymous posts.<br /> By
default, if a user has already registered and created a regular
account on the website, that email can no longer be used for anonymous
posts. If you want to allow regular users to be able to publish as the
anonymous user role, enable the <strong>Anonymous publishing
PET</strong> sub-module. However, you may override this behaviour by
setting this option. This security implications, as somebody familiar
with your users will be able to guess the email-address of a
registered user and use this to post harmful content which the regular
user may be blamed for. It is recommended to turn of stickyness for
self-activation if you enable this option.</li>
</ul>
<p>The setting for verification persistency determines whether users
need to re-verify after they've verified (or have been verified)
once. The settings are:</p>
<ol>
<li>Make verification persistent.<br />
If this option is set, a verified email-address will be trusted,
relieving the user from the task of re-verifiying on return visists to
the site (see “Verified” below).</li>
<li>Verification persists as long as the same IP is used.<br />
If this option is set, a verified email-address will be trusted if the
IP-address used to post matches the previous IP-address used used
along with the same email-address.</li>
<li>Require verification for each posting.<br />
If you set this option, users will have to re-verify their
email-address again every time they post. This is the most secure
setting, but also bit more of a burden on the user.</li>
</ol>
<p>The setting for the attribution or byline (“To whom should
anonymous postings be attributed”) can only be used if the retention
period (set on the Privacy tab) is set to “Indefinitely”. When
accessible, it lets you choose between the following three
options:</p>
<ol>
<li>Use the default alias for anonymous users.<br />
This means that all anonymous postings will share the same
byline.</li>
<li>Use an generated persistent alias (format “userN”).<br />
This means that anonymous postings will associated with the same
email-address will share the same byline. The byline will be
automatically generated and cannot be personalized.</li>
<li>Allow the anonymous publisher to set the byline.<br />
This works like the previous option, but since the alias is selected
by the user, it may be personalized.</li>
</ol>
<p>If you select option 1 (use some default alias) after having one of
the options for a persistent alias active for some time, the aliases
will no longer appear. They will, however reappear if you select
option 2 or 3.</p>
<p>If you select option 2 (generated alias), it will only affect new
anonymous publishers. email-addresses already known by the system
will retain its existing alias/byline association.</p>
<p>If you select option 3 (user sets byline), the field to define an
byline will appear on the content creation form for anonymous
publishers. If the email-address given by the user already has an
byline associated with it, the new byline will take presedence over
the old for all anonymous postings unless the user leaves the field
blank. If the email-address given is unknown and the user leaves the
field blank, an alias will be generated for the user.</p>
<p><strong>NOTE:</strong> The privacy settings of this sub-module let
the administrator purge the information that links email-addresses to
anonymously published content from the datebase after some pre-set
retenion period or immediately. This will delete all information
linking specific content to activation email-addresses. After
purging, the it will no longer be possible to use an alias as a
byline. Purging is not reversible.</p>
<ul>
<li>Guidelines for the byline.<br />
If you select option 3 (user sets byline) you may provide a short text
of guidance in this field. This field is not used by options 1 and
2.</li>
</ul>
<p>The last four settings are:</p>
<ol>
<li>Administrator's email-address:<br />
If you opt to send email to the administrator when anonymous content
is created, you need to provide a vaild email-address for the
administrator.</li>
<li>Verification email address field weight:<br />
To control where on create content form the verification email-address
field is placed, you may specify a weight for this field.</li>
<li>Number of hours to retain anonymous posts before auto-deletions
removes it:<br />
Spammers often creates contents on sites that allow them to do so, but
almost never act on the verification email. This settings can be used
to automatically delete anonymous posts if the email has not yet ben
verified after the number of hours you set here.</li>
<li>Number of anonymous posts allowed from a single user email/ip
allowed within an hour:<br />
For flood control, you may set the number of anonymous posts allowed
from a single email-address or ip-address within an hour from 1 to
98. Use 99 for no limit.</li>
</ol>
<p>Remember to press “Save configuration” when done.</p>
<h3>Message templates</h3>
<p>In this panel, there are four fields that let the administrator
customize the email-message sent to non-authenticated users when they
create content. The first field is the subject, the rest of the fields
may go in the body. Other settings determine what fields are used.</p>
<p>There is also two templates (subject and body) for the email sent
to the administrator.</p>
<h3>Moderation</h3>
<p>This panel shows all the comtent published anonymously that have
been verified by email. It lets the administrator publish or
unpublish.</p>
<p>The moderation workflow of anonymous publishing is tied to the
option “Allow self-activation”. If you check this option, the user is
allowed to selv-activate content by verifing his or her email-address.
If you leave this option unchecked, content created by
unverified anonymous publishers will not become activated until it is
approved by a moderator.</p>
<p>If you do not check the options “Allow selv-activation”, the
content will not be published when the anonymous user verifies is or
her email. In addition, the moderator must activate the content for it
to be published.</p>
<h3>Verified</h3>
<p>This panels list all the verified emails and their current
status.</p>
<p>Also listed is the alias associated with each email. The alias is
always generated, but will only be shown publicly if you check
“Associate a generated alias with contents published anonymously”
under main settings.</p>
<p>Also listed is IP-address associated with each email. The
IP-address listed will be used for blocking if you mark the email as
blocked and you've checked “Use IP-address for blocking” under main
settings.</p>
<p>email-addresses that are blocked from anonymous publishing is
shown with a check-mark in the column “blocked”.</p>
<p>To block, set a check-mark in the row of the email-address. To
unblock, remove this check-mark. To make changes take effect, press
“Execute”.</p>
<p>Note that a checkmark in the “blocked” column will only prevent the
user from posting anonymously. No other part of the site's
functionality will be affected. Unlike the ban IP action you may take
in the “Unverified” and “Spam” panels, the blocking is handled by this
module, not by Drupal.</p>
<p>This status of blocked is only meant to be used to block abusive
human users from publishing anonymously, not to ban spambots.</p>
<h3>Unverified</h3>
<p>This panels list all the emails IP-addresses that has been
associated with anonymous publishing that has not yet verified by
email and how long it has remained unverified.</p>
<p>This panel provides a chortcut to admins that want to delete
unpublished spams posts and at the same time ban the IP-address used
to post it. Placing a mark in the “Select” column to the left
of an posting listed here will select the posting for one og three actions:</p>
<ol>
<li>Delete: Delete the posting but take no further action.</li>
<li>Delete+Ban IP: Delete the posting and add the IP-address used to post it to the Drupal's <code>{blocked_ips}</code> table. Banned IP-addresses will not have access to any part of site at all.</li>
<li>Approve: Approve the posting. This will mimic the action of the anonyous publisher verifying the posting using the emailed link.</li>
</ol>
<p>To unban a banned IP address, navigate to:
<span class="nav">Configuration » People » IP address blocking</span>
and press “delete” for the IP-address you want to unblock.</p>
<h3>Spambots</h3>
<p>The spambots panel shows the IP-address of the “Top 10” spambots
targeting the site, along with some simple statistics. You can ban an
IP address by placing a check-mark in the “ban IP” column. When you
press “Execute”, the IP-address will is moved to the list of
IP-addresses blocked by Drupal.</p>
<p>To unban an IP address, follow the same procedure as suggested
above.</p>
<h3>Privacy</h3>
<p>While no email-address or username is made available to outsiders,
the email-address and IP-address associated with content is by
default retained indefinitely, and can be extracted from the
database. If your site is used to publish sensitive material, you may
want to limit the period the record that links emails and
IP-addresses to specific content is retained.</p>
<p>For a very sensitive site, you may want to set this to “Delete
ASAP” to delete at next cron run. But you may also opt to retain for a
limited time (from an hour up to 1 month) to give you some time to
pick up the email-addresses or IP-addresses of spammers and block
them. The purging of email-adresses and IP-addresses is done by cron,
so you need to run cron at least as often as half the maximum period
set to be sure identifiers are purged within the time limit.</p>
<p>The button “Purge now” bypasses cron and purges the identifiers
instantly.</p>
<p><strong>Note:</strong> Purging, as described above, only purges
identifiers from the tables belonging to this module. It does not
touch other places on your site where identifying information can be
found, such as the webserver logs. This means that if you want to
protect your anonymous publishers against law enforcement doing
forensics on your site, the anonymity provided by this module
is <em>not</em> sufficient.</p>
<h3>Other administration</h3>
<p>If you want users that are not logged in to be able to create
content, you also need to navigate to <span class="nav">Configuration » People »
Permissions</span> and check the following for the anonymous user: “View
published content”.</p>
<p>Then for each of the content type(s) you want to allow anonymous
publishing for, check the following for the Anonymous user: “Create
new content”.</p>
<p>To allow the anonymous user to post comments, grant the following
permissions:</p>
<ul>
<li>“View comments”</li>
<li>“Post comments”</li>
<li>“Skip comment approval”</li>
</ul>
<p>To get rid of the “(Not verified)” string that appears next to the
user name of any comment posted by the anonymous user, navigate
to <span class="nav">Configuration » Appearance » Settings » Global settings</span> and
untick the following: “User verification status in comments”.</p>
<h2>Trouleshooting</h2>
<h3>No email</h3>
<p>The <strong>Anonymous Publishing CL</strong> module uses
Drupal's <code>DefaultMailSystem</code> to send out
verification/activation emails (refer to the API documentation at
api.drupal.org for the function
“<a href="https://api.drupal.org/api/drupal/includes!mail.inc/function/drupal_mail_system/7.x"><code>drupal_mail_system</code></a>”
for details). It uses the method “mail” to send the mail, and prints
out the message:</p>
<blockquote>
<p>“A link and further instructions have been sent to your email-address.”</p>
</blockquote>
<p>after after the mail was successfully accepted for by the mail for
delivery.</p>
<p>If the mail system rejects the message, it prints out:</p>
<blockquote>
<p>“Error mailing activation/verification link.”</p>
</blockquote>
<p>If you get the error message, then there is probably something
wrong with the configuration of mail on your Drupal site.</p>
<p>Here are some things to check if you do not receive an email after
posting as anonymous, despite the fact that you're told that a link
and further instructions have been sent to your email-address:</p>
<ul>
<li>The first thing you should check is that Drupal can send email at
all. You can try using the <strong>Contact</strong> module (part of
core) or you can request a password reset by logging out and clicking
the “Request new password” link in the login block.</li>
<li>Next check that verification/activation emails are not stopped by
some spam-filter at the receiver end. The sender of the emails sent by
Anonymous Publishing is the site's email-address. You can inspect this
at: <span class="nav">Configuration » System » Site
information</span>. Search your-spam folder for recent emails sent
from this address. Also note that there are some mail services
(e.g. gmail.com, mail.yahoo.com) that have spam filters that consider
the verification/activation emails from this module as spam and
silently delete them. For testing, use a mail service where <em>you</em>
control what is filtered.</li>
<li>When testing this, make sure that the email-address given by the
anonymous poster is valid, and goes to a mailbox you've access
to.</li>
<li>Make sure that the site's email-address is valid. Look for bounced
verification/activation emails in the mailbox belonging to the site's
email-address.</li>
</ul>
<h3>Warnings from schema module</h3>
<p>If the
<a href="https://www.drupal.org/project/schema"><strong>Schema</strong></a>
module is enabled, you may get warnings saying: “no schema type for
mysql type date”.</p>
<p>The reason for this warning is that this module uses
the <code>date</code> datatype if it is supported by the database,
but <code>date</code> is <em>not</em> a Drupal datatype. Since the
module is designed to use <code>varchar</code> as a datatype for dates
if the database does not support <code>date</code>, this should not be
a problem and you should ignore these warnings. You may turn these
warnings of by navigating to:
<span class="nav">Structure » Schema » Settings</span>
and ticking “Suppress schema warnings.”.
<p>For more about this, see the comment linked to in the issue thread:
“<a href="https://www.drupal.org/project/schema/issues/1237974#comment-4984116">Schema module reporting some Date discrepancies</a>”
on Drupal.org.</p>
<h2>Spam protection</h2>
<p>If you allow anonymous publishing your site will probably be
targeted by spammers, both of the human kind, and spambots. There is
already some built-in protection against spambots in this module.
These built-in features may be suffiscient to keep spam at bay. If you
need more protection against spam, there are several spam control
projects on Drupal.org that will help you do that.</p>
<h2>Known glitches</h2>
<ul>
<li>The core comment module allows anonymous publishers to pick their
own non-persistent byline when they post a comment. This conflicts
with the persistent alias used as a byline by this module, so this
feature in Drupal is disabled when this module is enabled.</li>
<li>When a persistent alias is linked to content, the
alias will not appear when there is no content <em>directly</em> associated
with the display (e.g. on the forum landing page). Instead the system
default name for the anonymous user will appear.</li>
</ul>
