Hello all! I’m running into a roadblock building this side project that uses the Discogs oauth. I’m authenticating users using the api and would like to store the authentication data in the req.session object provided by express-session alongside a mongodb store. I save the data to the session object, then request a save to the store in the code below:
router.get('/authorize', function(req, res) {
var oAuth = new Discogs().oauth();
oAuth.getRequestToken(
config.get('DISCOGS_KEY'),
config.get('DISCOGS_SECRET'),
'http://localhost:5000/oauth/callback',
function(err, requestData) {
if(err) console.error(err);
req.session.requestData = requestData;
res.redirect(requestData.authorizeUrl);
}
);
});
router.get('/callback', function(req, res){
var oAuth = new Discogs(req.session.requestData).oauth();
oAuth.getAccessToken(
req.query.oauth_verifier, // Verification code sent back by Discogs
function(err, accessData){
if(err) console.error(err);
req.session.accessData = accessData;
req.session.save(function(err) {
console.log('saved?!');
res.redirect('/list');
});
}
);
});
I try to recall req.session in another endpoint in the code below, and the data I saved doesn’t persist.
router.get('/me', function(req, res) {
console.log(req.session);
var dis = new Discogs();
dis.getIdentity(function(err, data){
console.log(data);
});
});
At first I thought the data wasn’t being saved to the store, but after I checked the data was there, it just wasn’t showing up when I called req.session in that route.
Any help or recommendations would be awesome!
In each of those routes, try logging out session.id and see if they all match.
@PortableStick they are different… I assumed they would be the same. Is there a setting I need to modify to fix this?
I honestly have no clue, but I agree that they should be the same. It’s Express, so if there’s any configuration to do, I’d imagine it’d be with some middleware somewhere. I’ve only done trivial work with Node/Express and all of my full stack work has been in Rails. @JacksonBates might have something to add, or at least know better how to find the answer.
I think @portablestick is right about the need for middleware, but I haven’t checked properly.
I would expect you’d need to do the auth in your server.js file (or at least call your auth module from server.js) and then pass the auth session along as middleware using app.use(…)
One thing that helps me when using complicated libraries like this is to do a search on GitHub for a line of code from that library in use, and then I pour over the repo to see how it is all wired together.
1 Like
@pdotsani,
Not an expert but interested in your thread. Let me try to help:
First thing I would ask is why not implementing Passport.js to manage Discogs OAuth? This doesn’t have to do directly with your session though.
I see the following steps where session is affected by changing attributes:
req.session.requestData = requestData;
req.session.accessData = accessData;
req.session.save(...) // a method you implemented at the config of the session
and then you fetch for session only at
console.log(req.session)
Unless all those attributes and methods are at the configuration and call a DB middleware or similar it is possible that that you are saving CRITICAL information in the session cookie?? That is:
If so I can quickly suggest you should pass to session a single id that doesn’t identify the OAuth procedure but rather locates the record in your DATABASE, in order to keep a safe interaction. Otherwise, I suspect that the OAuth could be easily hijacked.
The usual procedure I am more aware of (when using SESSIONS WITH COOKIES as you are apparently doing here) when using express.js is:
- use Passport as a middleware to manage the OAuth
- save the accessData into a secure database pointing to the current session’s user (this can be also a DB used for that purpose only; not clear if implemented in your case or how)
- after finishing the OAuth, use passport to serialize/deserialize the session serial ATTACHING to user session the id of the user ONLY (NOT the accessData, assuming it is critical for the OAuth procedure)
- fetch between parties using the serialization/deserialization procedure when required
It also seems (according to readings again 
) that the session saves data on the server side. I suspect (but haven’t tested) that you could end up seen different session tokens using a console.log from the server if you are checking the session serial after each change you made. I would say it is not the case because as someone suggested above you used session.id attribute at some point? I also assume you are verifying session id AFTER the OAuth finished (Question you could try to answer: Did you really FINISH IT?)
Which also makes me wonder if all those changes in attributes you are making at the config of the session would really have changed your session ID assuming that you always expect to see an assigned unique id fraction of the session by simply calling session.id? Is this true?
Anyway this is what I am learning, I can hardly help you more than that at the moment but hope this helps.
@evaristoc @JacksonBates Thanks for your help! I’m currently using express-session and connect-mongoDB-session to manage the session store. When I fetch req.session.accessData or req.session.requestData, it returns undefined. I can say for sure that the session store is saving this data (which I need at the moment to access the api authorized routes), but for some reason it’s creating a new session id after the res.redirect('list'). I think the passport middleware recommendation might be the best next step.
@pdotsani
From many things I am learning here sessions and auth are still some of the few things that I still find hard to grasp, personally.
Apart of the readme of session-express as recommended above, here a thread in stackoverflow about sessions that could help you?
Also not sure if the following behaviour is applicable to session-express:
http://singhtechies.com/asp-net-session-sessionid-changes-between-requests/
Success!