Multiple Moqui Sessions Created on First Load from Next.js

Technical Questions
1

The Problem:

  • On first load, multiple API calls are made in parallel from different components.
  • Since there’s no session cookie yet, the backend (Moqui) creates a new session for each request.
  • This results in 4–5 separate sessions being created unnecessarily.

What I Need:

  • A way to ensure that all initial requests share the same session, even before the user is authenticated.
  • A recommended pattern (middleware, proxy, etc.) in Next.js to manage and persist the Moqui session cookie for guest users across multiple API calls.

Any suggestions or best practices to handle this cleanly would be greatly appreciated!

2

Any suggestion?

3

When multiple users access the Moqui server, the server generates a separate session for each user, right? When you talk about multiple API calls, whether the Moqui server treats them as coming from one user or multiple users is not related to Moqui itself. If you want the server to create only one session for multiple API calls, you need to first make a request to the server to obtain the jsessionid, and then include this jsessionid with all subsequent API calls.

1 Like
4

We’ve been using Astro and/or Quasar in front of Moqui and talk to the ERP with REST via RTK for SSR or PWA but we are using OAuth. We do get a lot of anonymous visitor records in the log but we have a cronjob clear that out.

1 Like
5

I like the idea of session cleanup. Although You don’t need necessarily a cronjob for that, moqui itself could clean them with a scheduled job instead.

1 Like
6

True! No reason not to do it with Moqui.

1 Like
7

@f.karim Did you fix what you needed?

8

I think whether or not fixed, we do have an issue that should be addressed. Simply flood the server with requests without a JSESSIONID and observe your /runtime/sessions directory filling up. If you combine this with long lived sessions (say a day or a week) then you might have a serious issue on your hands. We need a way to ignore such requests or limit them past a certain number or using some other common solution. Furthermore, even if you do build a massive set of sessions, I think some kind of directory structure might ease the pressure on the system. Say for example runtime/sessions/2025/04/17/*

1 Like