Multiple sessions being created on each endpoint request

Technical Questions
1

When our Next.js frontend calls protected endpoints on a Moqui backend, a brand-new session is created each time, even though we’re sending the saved moquiSessionToken and the user is already logged in.

Steps to Reproduce

  1. Log in via the Next.js app (successfully stores moquiSessionToken in localStorage).
  2. Navigate around the UI so that it calls several backend endpoints (e.g., fetching user profile, channels, dashboard data).
  3. Inspect the backend logs (or database): you’ll see a new Moqui session created for every request, even though the same token is sent each time.

What we are Sending

GET /api/rest/s1/eyon/viewer/channel HTTP/1.1
Host: 127.0.0.1:3000
Accept: application/json
Content-Type: application/json
moquiSessionToken: JpPjySV2WSPVsk8jrwHd

Expected Behavior

  • The backend should recognize the existing moquiSessionToken and reuse the associated session.
  • No new sessions should be created on subsequent requests.

Actual Behavior

  • A new Moqui session is created on every API call, regardless of the moquiSessionToken header value.
  • User’s login state appears intact on the frontend, but backend session proliferation causes performance and storage issues.

What We’ve Tried

  • Verifying that moquiSessionToken is correctly read from localStorage and added to every request.
  • Checking network logs: the header is present on each call.
  • Testing with both moquiSessionToken header and Cookie-based sessions, same problem persists.

Questions

  1. Are we missing a configuration in Moqui to reuse sessions by token?
  2. Should we be sending something else (e.g. a session cookie) instead of moquiSessionToken?
  3. Any tips on debugging Moqui’s session management to see why it’s ignoring our token?

Thanks in advance for any guidance!

2

Yes I confirm this. Essentially, forgetting passing or not passing cookies or whatever. There seems to be an issue. What if an API client never sends cookies. It leads to an explosion of sessions in the system (kind of a memory leak). Shouldn’t we protect against this? I saw the runtime/sessions fill up quick

3

I think this issue is caused by the jsessionid not being sent to the server correctly. Just ask AI how to send the server’s cookies with Next.js.

BTW，how do you check the http sessions?

1 Like
4

@zhangwei yes, but not sending the session to server causes explosion of sessions. It’s a memory leak or issue that needs to be solved I think even after sending it. Server should not build millions of files in runtime/sessions

5

I can confirm this problem. I just checked on my production deployment and it seems that a new file is created in runtime/sessions with every api call. Currently I only have about 190 files. Not sure how this sessions management works, but wouldn’t the sessions be expired and deleted after a certain period of time? Also, in my case I’m just using REST api calls, which I expect to be stateless anyway, so the session management is not needed. Wouldn’t it make sense to have the option to disable it for REST calls?

1 Like
6

I tested a POST request to http://localhost:8080/rest/e1/examples using Postman, which automatically includes the JSESSIONID in each request. No additional files are created in runtime/sessions.

1 Like