Support.nabble.com



Re: Registered Members Can’t LoginTests and Analysis of the ProblemProblem: 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” formAuthenticated --- 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 only2. Completed the “Register Now” form, and either/or:A. User verified e-mail address using Nabble’s e-mail to user, and/orB. User also then completed the “Request Access” formRegistered --- 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 serRegistration FormAuthenticated ListMembersListPeople/Members ListLog InUser-nameE-mailPass-wordYN1TomBoyjohnsmith114@magic#TomBoy <johnsmith114@>TomBoy <johnsmith114@>RegisteredY2MrCooljcorbin@T2#h!okjcorbin <jcorbin@>jcorbin <jcorbin@>UnregisteredN3Ninjabglee@zenseedNinja < bglee@>Ninja <bglee@>RegisteredY4747Pilotfastfly@banshee fastfly <fastfly@>fastfly <fastfly@>UnregisteredN5MagManAngel245@tinkererMagMan <Angel245@>MagMan <Angel245@>RegisteredY6BusyBeemjones@beehivemjones <mjones@>mjones <mjones@>UnregisteredNObservations: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 stageB. Whether Nabble requires every user to complete the “Request Access” formAs 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 stepNeither user used the Request Access processUsing 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 ListsAny 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@.” 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 <john_smith@.” It would seem that this syntax should not apply if there’s a Username available. It’s relatively academic, since an administrator has no choice but to input the user information into this Members list exactly as Nabble has provided it in the Authenticated list. Repeated tests trying to enter a different syntax in the Members list only caused it to, after saving, revert back to what is in the Authenticated list. That includes attempts to simply delete the entry...it just comes back. Even attempts to enter the user information before the user information appeared in the Authenticated list caused the Members list entry to later change to that in the Authenticated list. It is not incorrect to have the two lists synchronized, of course, so this issue only applies in situations wherein the entry in the Authenticated list does not match the original information in the user’s Registration “Register Now” form. For administrators, there is no way that the original Registration information is fully disclosed to you, of course. So an administrator’s ability to even know that the Authenticated list is wrong is moot. Preliminary FindingsThe original problem the tests addressed are that 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 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 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download