Closed DylanBelka closed 4 years ago
We are going to put this on hold for merging until we set some other things up to ensure that nothing goes poorly once deployed since the JWT encodings may be different from the bcrypt encodings.
@mjrb For some clarification on what @DylanBelka said, since JWT's store information, encoded into their tokens we originally were sending redundant data (with the email and expiration date within the token as well as sent outside of it in the JSON). For example, we were sending
{ "auth":
"token": jwt_token
"valid_until": time
"email": email
}
where jwt_token has:
{
"exp":time
"email":email
}
This was to ensure when we deployed there would not be an issue where frontend broke as a result. Since then, we have had a meeting with the frontend and we removed the redundant data and only have the expiration date and email encoded into the JWT. This could also potentially break other applications (such as mentorq, teambuilder, etc.) when it gets released.
So now we are just sending:
{"token": jwt_token}
Resolves #76 Essentially replaces the token string in request bodies which used to be a randomly generated uuid with a stringified jwt that encodes user's email and an expiration timestamp. Frontend and other consumers of LCS will need to be updated to properly take advantage of jwts. For now these applications will still be able to work without modification as they should not be actually using the token themselves for anything.