Open daveboulden opened 4 years ago
I have finally got to the bottom of the issue, so will share here in case anyone else comes across this issue when slipstreaming a new release into their existing code.
I had not properly updated the auth
node in config/default.js
. I had:
jwt: {
secret: '0dxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
accessTokenSecret: '0dxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
},
and it should have been:
jwt: {
accessTokenSecret: '0dxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
refreshTokenSecret: '1axxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
accessTokenLife: 3600,
refreshTokenLife: 2592000,
},
I suspect this was enough to cause the token creation to fail in the generateResponseTokens()
function in cipherHelper.js
and as the error is not caught in that lower level function, it percolated back up to the passport.authenticate()
call in the /login
route declaration in authController.js
.
Could I request that Akveo produces some documentation for bundle owners that describes the process and data-flow within the authentication process at the back-end? It would help greatly when the code changes with updates between version releases.
I have slip-streamed the latest version of the node-ecom bundle back-end into my pre-existing project. If I use a pre-existing JWT token, I can access data through the various API endpoints, but I can't get "login" to work.
The relevant code in my authController.js file looks like this:
When accessing the API via the Swagger UI (or externally from Postman or my front end) the
if (err || !user)
condition is always true because always:err
= nulluser
= falseCan someone give me a pointer as to where to check for errors upstream in my code as it seems the
passport.authenticate
function may not be returning the values that are expected.