Ticket: User Management M220JS - loginUser

Feels like I’m misunderstanding something. What is the content of the jwt field? What is jwt?

static async loginUser(email, jwt) {
try {
// TODO Ticket: User Management
// Use an UPSERT statement to update the “jwt” field in the document,
// matching the “user_id” field with the email passed to this function.
console.log("jwt: ", jwt)
await sessions.updateOne(
{ user_id: email },
{ $set: { jwt: ??? } },

JWT stands for JSON web token. You can check Mongo Compass mflix database, session collection for more info.

Thanks! Why is not the following ok?

await sessions.updateOne(
{ user_id: email },
{ $set: { jwt: jwt } },

Thanks again! Good suggestion for a test update!

Actually I don’t think you fixed anything.

Please understand that you do NOT alter the provided test cases under ANY circumstance. Doing so is likely to lead you to an incorrect result.

In the case of your assertion:

Basically that’s not true. The function of await is that the Promise is waiting to be returned before any local and subsequent code are executed. Being that:

const sessionResult = await UsersDAO.getUserSession(testUser.email)
delete delete sessionResult._id


   .then(sessionResult => delete sessionResult._id)

Are basically exactly the same thing, just with a different way of expressing things that is meant to be more logical and cleaner to read. In either case, it’s just not possible for the “next line of code” to execute before like you are claiming. That’s a callback implementation mistake, but not what we are dealing with here.

The ONLY way that sessionResult is effectively undefined or null is because their was no data returned from the getUserSession() function, either because the function implementation is incorrect, OR the test “data” is incorrect, and probably because you’ve been messing around with the unit test code, just as has been stated as something you do not do.

Hope that teaches you something. As basically you seem to have Promises and Callbacks confused as to how they work, and at the very least you need to learn to *not touch the unit tests, as the course instructions and various posts here have also said various times.

1 Like

Thank you for the clarification, I will reverse test case to it’s previous state and won’t mess with it again.

Hi I am facing this issue , not sure how jwt value gets modified to this “someneatjwt”
any suggestions please?

Expected value to equal:
{“jwt”: “hello”, “user_id”: "magicz@cats.com"}
{“email”: "magicz@cats.com", “jwt”: “someneatjwt”}

Also what i don’t get here is how is user_id of sessions related to email , please help.

I am simply stuck on adding a user. Just not happening. I’ve tried everything I can think up. And always come back to everything else passing except this. I know I am missing something, but it is just not coming to me. All the other tests pass for this ticket! Just not this one.

1 Like

I’m in the same position.

@Rahul_Singh18, for the case about jwt being modified that is very possible if there is another entry with the same user_id or more likely because they lab ask to add a document with the field user_id and you add one with email.

As for your question:

There is no relation except that it is supposed to be unique. They could have use the _id field of the user from the users collection, but it is easier to debug when it is human readable.

Thanks @steevej-1495

@interglobalmedia can you be more specific about the error you are getting.

I think some of the confusion here is due to the sessions collection having a different schema than the users collection.

When adding a user, the provided arguments to the addUser function can be used as is with little or no modification (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals)

When logging in a user, we want to do a few things.

  1. Create a user_id key in an object that holds the user’s email.
  2. $set the jwt key to the value of the jwt passed in. You may find this easier to do as { $set: { jwt } }
  3. Only create a document if one doesn’t exist, otherwise modify. Upsert is very handy for this.

@nathan.leniz thank you, now the confusion is cleared related to schema.

But i still have one doubt , in sessions collection we already have a key user_id, creating a second key with same name will there be no conflict ?

@CARLOS_64548, you should not post solution code. That’s against the forum policy. If you give people the solution they won’t learn.

1 Like

Thank you @CARLOS_64548 for trying to help. In hindsight, I had the correct code (from what I remember), so may have been related to one of the other methods in the user-management ticket. Careful with posting code in its entirety.


1 Like

Hi! Im stock in what I think is the point 2 in login user, Im not finish to understand what Im doing wrong this is my code…

so…what I think to know is that a jwt generates a token from a password provided…so I tried
$set:{password:jwt} also I tried $set:{ jwt } …but Im setting the value jwt of the object “sessions”. Do Im right?
so in that case…why the test fails? I hope been specific enough.
Regards from Argentina. Sorry for my bad english…:see_no_evil:

The user_id IS the email.
user_id: email

why are you returning upsert:true ?