Registering Users Does Not Work Properly

I’m using the JavaScript SDK example to create users in my testing app (backendless-js-sdk/examples/user-service/index.html).

When I register, all seems to go well. However, I never get an email confirmation (Require Email Confirmation is turned on).

Additionally, I have questions concerns about the following:

    In the "Users" table of the data browser, I see almost no information about the user: There is no unique user id, no created timestamp, I can't see the "userid", the email fields are empty, I can't edit the user in any way, there is no "confirmation email received" field, there is a pswrd and password fields, why 2 fields that seem like passwords? When I register, the API sends back a JSON response. The response has a unique ID, email, pswrd, and "userid". The pswrd and userid are empty. Shouldn't the response have the "userid"? Shouldn't the response have a "email_confirmed" field?
So, I've spent a few minutes typing this question. While doing so, I've registered another user. This time, the User table DOES show the User ID, it DOES show a "password", AND it shows a "pswrd" that is not encrypted or disguised. So, third time is a charm for registering users? I still did not receive an email confirmation.

The “userclassprops” request method does not return any information about whether the email is confirmed or not. Since I can’t determine if the user is confirmed or not, I can’t allow them to use the app.

Could someone please address these concerns?

Mark,

Thanks for the response.

The “pswrd” field in the Users table was generated dynamically because the sample form had it as a field. That explains why it exists and was not encrypted.

Identity is set to email. I think you really need to automatically assign identity to a GUID or auto incremented index.

So, now that explains those issues. Unfortunately, I can’t fix the problem. I tried to add a “usersId” field as a string to be the identity. The GUI does not allow this as the existing users new “usersId” field is blank. I can’t edit those records or delete them.

So, I started a new app and setup the “user” table before any user events occurred:

    email - required, string firstName - required, string lastName - required, string password - required, string userId - required, identity, string
Now, when I attempt to register a user via the demo example, all the fields show up in the form (nicely done). However, when I try to register, I get :
    {"message":"Unable to register user. Missing identity value for 'userid'","code":3013}
Of course, the userId field really shouldn't be on the form. So, trying to set it fails, but leaving it blank on the form also fails because it is required.

So, now I can’t proceed again.

Suggestions?

Justin,

please keep in mind that the field marked as “identity” is also used in the Login API call along with the password. This is how your users will be identifying themselves. As a result, any field you choose to be the identity must be present in the registration form.

Regards,
Mark

The problem with email confirmations has been fixed.

Mark

I’m confused by that. I expect a backend to GENERATE a unique key for each record. For example, I used backendless API and example code to populate a “Task” table. It generated an id of “0bb5ffea-fbe3-491b-85b8-45b8e87XXXXX” when I added a task. It also generated “created” and “updated” fields. In the backend, the “Task” table is also editable.

So, the “user” table doesn’t produce a unique id key when a user is added? It doesn’t auto generate “created” and “updated” fields?

I am still using your example “user-service” code. It still does not work. I AM entering the “userid” field that I made “identity”. It is still responding with :

{“message”:“Unable to register user. Missing identity value for ‘userid’”,“code”:3013}

Correction:

I am NOT sending back the userid code for some strange reason. I am using the unmodified code from the SDK examples for “user-service”. The problem is explained below.

TL;DR : The example code provided with the SDK has a bug in it.

I have setup my “User” table as :

    email - required, string firstName - required, string lastName - required, string password - required, string userid - required, identity, string
When the code requests the "userclassprops", it returns the following:
[{"name":"userid","required":true,"type":"STRING","defaultValue":null,"identity":true,"selected":true},{"name":"email","required":true,"type":"STRING","defaultValue":null,"identity":false,"selected":true},{"name":"password","required":true,"type":"STRING","defaultValue":null,"identity":false,"selected":true},{"name":"firstName","required":true,"type":"STRING","defaultValue":null,"identity":false,"selected":true},{"name":"lastName","required":true,"type":"STRING","defaultValue":null,"identity":false,"selected":true}]

When I fill out the form, it looks like this:

http://support.backendless.com/public/4jZaIUghrO3DlO3e2X71.png</img>

When I submit the form, it strangely submits the following:

{"userid":"","email":"Tester500@XXXXXXXX.com","password":"XXXXXXXXXX","firstName":"TestFirst","lastName":"TestLast","pswrd":""}

Where did that “pswrd” field come from? Why is the “userid” value blank? So, I go poking through the code. The “pswrd” comes from here:

Notice that this is the LOGIN function, NOT the register function.

function loginUser(form)/*function to check userid & password*/
{
    try{
        var user = Backendless.UserService.login( form.userid.value, form.pswrd.value );
        if(user != null)
            showInfo("Login successful");
        else
            showInfo("Login failed");
    }
    catch (e)
    {
        showInfo("Login failed. "+ e.message);
    }
}

So, why are fields that are referenced in the “loginUser” function getting passed when I am trying to register? Here is the answer:

function createUser( form ) {
    var user = new Backendless.User();

    $("input").each(function(){
        var propertyName = $(this)[0].name;
        if(propertyName)
            user[propertyName] = $(this)[0].value;
    });

    try
    {
        var register = Backendless.UserService.register(user);
        showInfo(" User successfully created");
    }
    catch(e)
    {
        showInfo(e.message);
    }
}

The createUser function is doing a query selector that finds ALL input elements in the DOM. Those input elements will include the register form AND the login form. So, while I am putting a “userid” in, the .each function is finding the first “userid” field in the register function, doing looping through all other fields, and overwriting my “userid” from the register form with the empty “userid” from the login form.

That mystery is solved!

Here is the fix:

Step 1:
The “register” form has an id “regForm”. The login form does NOT have an id. This needs to be fixed:

&lt;form class=&quot;form-signin&quot; id=&quot;loginForm&quot;&gt;

Step 2:
The query selector for the the register form needs to change from :

$("input").each(function(){

to

$('#regForm input').each(function(){

Now, I STILL don’t understand why the backend does not auto-generate details such as a unique key for user records, no created field, and no updated field. I also want to be able to edit the user records via the GUI.

Hi Justin,

Thank you for pointing out the bug in the example.

As for your question of whether there is a unique id assigned to user accounts by Backendless, there is one. If you look into the response for a successful login operation, it will look something like this:

{
  "id":"5FF545A9-1456-5851-FFD8-163E8B0FE900",
  "email":"mark1002@backendless.com",
  "password":"XXXX",
  "name":"First Name Last Name",
  "user-token":"XXXXX-XXXXX-XXXX-XXXX-2F78136E6700"
}

The “id” property is the one which Backendless assigns to a user record.

Hope this helps.

Regards,
Mark

Mark,

Aha! So there is one. It would be nice if it were provided in the response after the user is generated.

This still leaves the following questions:

    Why does the backend not autogenerate created field for user records? Why does the backend not autogenerate update field for user records? Why does the backend not allow user records to be edited? Why does the backend not show email confirmation field for user records? When a user is created or queried, I need to know if their email has confirmed.
Thanks for the input.

Justin

Hi Justin,

The result for the register API call also includes the “id” assigned to that user account.

Please see my answers below:

    Why does the backend not autogenerate created field for user records? Why does the backend not autogenerate update field for user records? Why does the backend not allow user records to be edited?
We made a design decision to keep the Users storage separate from the regular persistence storage. We are rethinking this decision now since many of the operations you mentioned (all of the above) would require special code which we have not put in place. The current thinking is to migrate the user storage under the generic persistence mechanism. So the answer to all of the "why's" above is "design limitation". We will get that fixed.
    Why does the backend not show email confirmation field for user records?
This is a great question. We have that information internally, but do not propagate it to the console (yet). I agree with you and see the value in showing it. We'll get it in there.
    When a user is created or queried, I need to know if their email has confirmed.
This is also a great suggestion.Regards,Mark

Hi,
I have the same problem with confirmation email not being sent.
I tried 3 different email accounts, to none of those email was sent.

[reply user_id=59][h4]Andrew Gubanov wrote:[/h4]Hi,
I have the same problem with confirmation email not being sent.
I tried 3 different email accounts, to none of those email was sent.[/reply]We had a temporary problem with the email confirmations, but it is fixed now. Please contact me directly if you still experience a problem (mark@backendless.com).

[reply user_id=48][h4]Justin Noel wrote:[/h4]Mark,

Aha! So there is one. It would be nice if it were provided in the response after the user is generated.

This still leaves the following questions:

    Why does the backend not autogenerate created field for user records? Why does the backend not autogenerate update field for user records? Why does the backend not allow user records to be edited? Why does the backend not show email confirmation field for user records? When a user is created or queried, I need to know if their email has confirmed.
Thanks for the input.

Justin[/reply]Hi Justin,

We posted an update to Backendless which addresses many of these issues:

    The backend now generates created/update fields You can add/edit/delete users from the console You can create relationships between the Users table and other tables.
Regards, Mark

Justin,

We’re looking into the problem with the email confirmations.

Meanwhile, could you please click “Users” and open the “User Properties” section. Which property is marked as “identity”? Backendless ensures that this property remains unique for all created users.

Please check what properties you have in the “Selected properties” column. The ones you do not need, simply click on them to remove from that list. Btw, the “userclassprops” response will return the properties from that list.

Regards,Mark

I still had email confirmation problem? Please help !!

Please let me know what email address that didn’t get the email confirmation.

i registered my gmail account to the system via my iOS app, but i didn’t get the email confirmation from the system. I also turned on the email confirmation require on dashboard. Please help !!!

I just checked and i see the last time a user registration email was sent to your email address was on Tue, Mar 1, 2016 at 9:49 AM US Central time.

On Wed, Mar 2, 2016 I also registered my email but no email confirmation was sent. Please check it !!

We had a problem with the mail server yesterday. It should be resolved now.

Sorry about the inconvenience.

Regards,
Mark

Hi Mark,on IOS,i have same problem,the email confirmation doesn’t arrive,but the email for registration yes.