Re: Registered Members Can’t Login
Tests and Analysis of the Problem
Problem: Some users are shown as “Registered,” while others are listed as “Unregistered” in
the People > Users & Groups > Members list. Unregistered users cannot log in. The test deals
with discovery of observable irregularities that may point to why some users become
Registered, while others don’t. Implications may point to corrupted databases.
The Environment: A forum application (free version on server n3), with Permissions configured
for Members only.
Test Protocol: To minimize/eliminate user errors attributable to users registering themselves,
only the Administrator completes the initial Registration “Register Now” form.
Terms: For consistency, this test uses the following terms:
Register/Registration --- Entering user data into the “Register Now” form
Authenticated --- For purposes of the test, a list of users whom Nabble “knows the e-mail
of the user,” i.e., acknowledges user as having either:
1. Completed the “Register Now” form only
2. Completed the “Register Now” form, and either/or:
A. User verified e-mail address using Nabble’s e-mail to user, and/or
B. User also then completed the “Request Access” form
Registered --- Nabble has defined this term to mean “Authenticated + Registration-Date”
Members --- A list of users that the Administrator creates (Options > Users > Manage
Users & Groups> Members) that, in this test, may or may not cause a user to become
either “Registered” or “Unregistered”
People/Members List --- A list in People > Users & Groups > Members that identifies
members as either “Registered” or “Unregistered”
How the Problem Is Evidenced: The following table shows variables that may be associated
with the problem.
U Registration Form Authenticated List Members People/ Log
s List Members List In
e User- E-mail Pass- Y N
r name word
1 TomBoy johnsmith114@aol.com magic# TomBoy TomBoy Registered Y
2 MrCool jcorbin@gmail.com T2#h!ok jcorbin jcorbin Unregistered N
3 Ninja bglee@hotmail.com zenseed Ninja Ninja Registered Y
4 747Pilot fastfly@comcast.net banshee fastfly fastfly Unregistered N
5 MagMan Angel245@aol.com tinkerer MagMan MagMan Registered Y
6 BusyBee mjones@gmail.com beehive mjones mjones Unregistered N
Observations:
The tests conducted included 30 users, most of whom were persons who provided the
administrator with their e-mail addresses, usernames, and passwords. A subset included
“artifacted” users that the administrator created by setting up e-mail accounts, usernames and
passwords so that the user experience would have a control group. The user information in the
above table is not of real users.
There should not be any “Unregistered” users represented in the above list. Those shown as
“Unregistered” have an error, and should have “Registered” status just like the others. The test
administrator sees an indicator of the problem of “Unregistered” users in the Authenticated list.
The syntax of how users 2, 4, and 6 in the table are reported in Nabble’s Authenticated list
indicate users that will not result in Registered users who can successfully log in.
Of the 30 tested users, how those destined-to-fail (2, 4, and 6 in the table) became listed in
Nabble’s Authenticated list is not fully discoverable by the test administrator because the
administrator has no accurate way of determining a variable that may have occurred at:
A. The user complying with (or ignoring) the e-mail verification stage
B. Whether Nabble requires every user to complete the “Request Access” form
As will be seen, no users who have filled out the initial Registration form should appear on the
Authenticated list before they perform the e-mail verification step.
Nabble has written that “Registered = Authenticated + Registration-Date.” The test administrator
interprets this as an explanation of under what conditions a user will appear as “Registered” in
the People > Members list. Unfortunately, such an interpretation conflicts with the test findings
which show that a user does not appear in the Authenticated list until that user has completed
the e-mail verification step. Completing the e-mail verification step should result in a user being
“Registered” as well, because it satisfies the need for having a “Registration-Date.” Nabble’s
statement does not clarify what purpose is served by an application administrator entering user
information into the Members list (Options > Users > Manage Users & Groups > Members).
Testing under conditions fully controlled by the administrator was conducted, where the e-mail
recipient was the administrator (some eight test subjects are exemplified here as users #1 and
#3 in the table). Here’s what did or didn’t happen:
Neither user appeared in the Authenticated list until they each performed the e-mail
verification step
Neither user used the Request Access process
Using a control group allowed the test administrator to perform the e-mail verification step. None
of the control group resulted in any “Unregistered” users. None of the control group used the
Request Access form. Ignoring the Request Access form did not impact the control users’ login,
posting, reply, etc., capabilities. Not using the Request Access form did, however, negatively
impact the application’s administrator. He/she was unable to ascertain whether or not any user
in the control group had, or had not, performed the e-mail verification function. This lead to the
administrator having to frequently scroll through the Authenticated list searching for new users
who should be added to the administrator-controlled Members list.
However, just because a user appears on the Authenticated list does obviously not imply that
any specific user is or is not registered and can/cannot log in. If the test does accurately show
that only users who have performed the e-mail verification step will appear on the Authenticated
list, then all six of the above tested users did perform that function and should be able to log in.
Therefore, all users in the above table must have completed the e-mail verification step,
otherwise their information would not appear in the Authenticated list. But, if verification of a
users e-mail also provides a “Registration-Date” that results in users being “Registered,” then
the tests and results do not support those outcomes.
The Authenticated vs. Members Lists
Any administrator’s use of the Members list (Options > Users > Manage Users & Groups) is
strictly limited to replicating the exact entry of a user in the Authenticated list. The administrator
cannot enter a line item that isn’t in a syntax different from the way it appears in the
Authenticated list. The tests conducted as they relate to users 2, 4, and 6 in the above table
showed that an administrator cannot rectify the syntax errors.
However, a separate test was conducted to ascertain whether or not information not displayed
correctly in the Authenticated list was perhaps still available in Nabble’s database. For example,
a controlled user (#5 in the table and created by the test administrator) attempted to change a
Password and a Username to those of user #6. Surprisingly, user #6’s Password was accepted.
It might be hypothesized that user #6 cannot log in because the Password is not correct in
Nabble’s database. In the alternative, perhaps Nabble allows multiple users to have the same
Password. However, user #6’s Username was unavailable to user #5, likely because it was in
Nabble’s database and associated with user #6.
Focusing only on the Username of #6, because it is the element in the Authenticated list’s
syntax that makes it different from those valid entries of users 1, 3, and 5 in the administrator’s
Members list, from the above test in the previous paragraph, it is apparent that #6’s Username
is in Nabble’s database, but it is not used in the syntax of either the Authenticated list (or usable
in the administrator’s Members list).
Remember here that Nabble’s login process does not require the user to provide a valid
Username…only a valid e-mail address and Password are needed. However, the Username is
used to identify the user in the People/Members List, as well as on any content the user might
post.
Looking at the table, we see that due to the syntax error in the Authenticated list, Nabble is
revealing a major part of every Unregistered user’s e-mail address as the user’s Username!
User #2, for example, is identified with the Username “jcorbin,” and that user’s e-mail address is
“jcorbin@gmail.com.” The correct Username is supposed to be “TomBoy.”
Noteworthy is that Nabble’s explanation of how to enter a user into the administrator’s Members
list shows a syntax that truncates a user’s e-mail address. Find this reference under “Members
Enter one user per row (more help)” where one cited syntax is “John Smith
Users & Groups > Members list.
Unregistered users cannot log in.
The tests have pointed to a number of issues, including that:
1. No user can appear in the Authenticated list until that user performs the verify e-mail address
function. This may be useful to administrators as an indicator that a certain user has (or has not)
performed the e-mail verification process.
2. The syntax of how Nabble displays the user in the Authenticated list has a 100% correlation
as to whether or not a user can achieve “Registered” status and be able to log in. There is no
mechanism in place for an administrator to actually know without careful scrutiny of the
Authenticated list, yet alone be able to notify Nabble that the syntax is flawed. At least an
application administrator can assume that no one can register without entering a Username into
that field on the Register-Now form. Even this is not a reliable indicator, because users can
enter their name (even perhaps part of their e-mail address) as their Username!
3. Application administrators’ use of the Members list (Options > Users > Manage Users &
Groups > Members) to determine whether or not a user is “Registered” or “Unregistered” begs
the question as to what value is gained by entering a user into the Members list. This may be
more related to situations that differ from the test’s environment of a strictly members-only
Permissions settings.
What’s likely “broken” is Nabble’s master database. Corrupted data from user Register-Now-
form sources seems the most likely cause of improper syntax in the Authenticated list. It also
points to a possibility that Nabble’s e-mails requesting verification may be linked to corrupted
database files that did not recognize a responding user to be properly associated with a
matching user in the database. This may be especially true when the Username and/or
Password fields are corrupted, since the Username is the missing data that should be included
in the Authenticated list. Password corruption would explain why users cannot log in.
If the database is, or not, corrupted still leaves unresolved what impacted administrators are to
do with those users who have been improperly identified as “Unregistered.” This should be
resolved without requiring any impacted users to re-register, re-verify an e-mail address, etc.
The test administrator has unfortunately validated the outcome of pursuing over 20 prospective
real-world users whom it was erroneously believed hadn’t performed functions such as e-mail
verification and/or completing a Request Access form.
Regards,
The Magazine Collector