Sessions created by Read API and Write API?

GameStep

Why do you create a new session for every api request? Make all requests in an open session or close the session after each request and open before starting a new

po

I don't want to create a new session for every API request. I was sending requests to the Read API, but I couldn't find clear documentation for it online. So, I just sent the bearer token I had previously generated for the Write API, and made Read API requests to endpoints with "?_uid=1" appended at the end, to authenticate as administrator.

My guess is that the Read API is where all of the sessions were being created. Is there a better way to open one session, make a lot of Read API requests, and then close the session? I'd love to do that. Could you please point me to a code example?

GameStep

@po said in Sessions created by Read API and Write API?:

I don't want to create a new session for every API request. I was sending requests to the Read API, but I couldn't find clear documentation for it online. So, I just sent the bearer token I had previously generated for the Write API, and made Read API requests to endpoints with "?_uid=1" appended at the end, to authenticate as administrator.
My guess is that the Read API is where all of the sessions were being created. Is there a better way to open one session, make a lot of Read API requests, and then close the session? I'd love to do that. Could you please point me to a code example?

It’s convenient for you to communicate via Facebook, I can give you my data https://www.facebook.com/GameStepLive

po

Thanks! I just added you on Facebook!

julian

@po nice to see you around again!

The read api definitely should not be spawning a new session for each request. It probably does because they're all unauthenticated requests, and so the server treats them all as new sessions.

However, 1.13.x (probably, not sure about 1.12.x) should not bother saving a session for each guest request. It was part of the session management fixes I committed.

If you've a plugin saving things to req.session, then that will cause unauthenticated sessions to persist.

po

Hi @julian! Nice to connect again as well! You guys are doing great stuff. When we were deciding which forum software to use for the new forum we were creating in 2020, it didn't take me long to choose NodeBB again!

I'm using v1.13.1 right now. The specific issue is that if I issue this command (with the appropriate master bearer token):

curl -H "Authorization: Bearer XXXXXX" "https://forum.poshenloh.com/api/uid/481?_uid=1"

then in my MongoDB console I see that db.sessions.count() increases by +1. The same thing happens when I go to the Read API endpoint /user/, which is what I really need. More worryingly, if I simply issue:

curl https://forum.poshenloh.com/api/user/sharpotter

with no tokens at all, then our db.sessions.count() also increases by +1, even though the return value is "not-authorized". This seems like it could create an easy DoS attack where our session database fills rapidly. Do you have a suggestion of what to do? Thanks!

Edit: because this was a potential DoS vulnerability, I turned on the privileges to allow guests to "View Users". Now there is no need to authenticate, and the session count does not increase. However, this is not optimal, because I'd like to protect user privacy by blocking access to this page for guests. Thanks!

julian

@po Can you try again without the Authorization header? I have a feeling that when you do this without an authenticated account, it won't create a new session...

po

Yes, I just did it without the Authorization header, and it didn't increase the session count. However, I was hoping to protect privacy by making these endpoints visible only to registered users.

<baris>

This happens because when a guest tries to access something they don't have access to we redirect them to login and set req.session.returnTo so that we can send them to what they want after they login. It happens here https://github.com/NodeBB/NodeBB/blob/master/src/controllers/helpers.js#L134-L139

julian

Mm... having server-side handle the returnTo would be more elegant than a querystring, but I suppose that's the tradeoff. Would work better as a qs then, now that we don't save sessions for guests.