Issue 24

[joeljoby02]

Worked on issue #24 to sync the upstream repo with the oss-slu repository

In general, this should be fixed by adding a rate-limiting middleware to the search routes so that requests to database-intensive search handlers are throttled. In an Express-style router, the recommended approach is to use a well-known library such as express-rate-limit, configure an appropriate window and maximum request count, and apply the limiter to the relevant routes.

Concretely for routes/search.js, we can import express-rate-limit, define a searchLimiter with parameters suitable for search operations (for example, a certain number of requests per 15-minute window), and then apply this middleware to both the '/' and '/phrase' routes. This can be done with router.use(searchLimiter) before the route definitions to cover all search routes in this router without changing existing handler logic, or by attaching the limiter directly in the route definitions (e.g., .post(searchLimiter, controller.searchAsWords)). Using router.use(searchLimiter) is simpler and keeps the behavior of controller.searchAsWords and controller.searchAsPhrase unchanged while ensuring that both existing and future search endpoints defined in this router are protected.

Implementation steps in this file:

• Add an import for express-rate-limit.
• Define a searchLimiter constant using rateLimit({ ...config }).
• Apply the limiter to this router using router.use(searchLimiter) before the router.route('/') and router.route('/phrase') definitions.
  No changes are needed inside the controller functions or elsewhere.

In general, the problem is fixed by adding a rate-limiting middleware to the affected routes (or to the router as a whole) so that calls to controller.searchAsPhrase (and other search handlers) cannot be made arbitrarily often by a single client. In an Express app, this is commonly done using a well-known library such as express-rate-limit.

The best fix here, without changing existing functionality, is to import express-rate-limit in routes/search.js, configure a limiter that is reasonable for search operations, and apply it to these search routes. To be minimally invasive and avoid affecting unrelated parts of the app, we can attach the limiter to this router only (e.g., using router.use(limiter) before defining routes, or applying it per-route). Since both / and /phrase are search endpoints that likely hit the database, protecting the entire router is appropriate and addresses all alert variants. The change is limited to routes/search.js: add a RateLimit import, define a searchLimiter instance near the top, and apply it to the router via router.use(searchLimiter) before the route definitions.

Concretely:

• Add import rateLimit from 'express-rate-limit' (ES module style, consistent with existing imports).

• Define a limiter configuration, e.g.:

  const searchLimiter = rateLimit({
      windowMs: 15 * 60 * 1000,
      max: 100,
  })

• Apply it before defining routes: router.use(searchLimiter) so that all routes in this router, including controller.searchAsPhrase and controller.searchAsWords, are rate-limited.

[thehabes]

Recommending that you remove the .github/workflows folder. You should also check in on your Actions settings. The goal is to make sure you are not using the upstream repo's Actions and Workflows as they do not make sense for your context. The RERUM Server Community Edition is a separate product. One of the action items is to set up your own Actions and Workflows for CI, CD, and security. If you determine you still want to using something upstream then we can work to make that happen when we cross that bridge.

It will be a good idea to review npm packages and use npm-check to attempt to update packages to the latest stable releases so you are starting from a good place. We need to do the same thing upstream but you should set yourself up so that you are not relying or waiting on us for anything. If you notice a package update causes breaking changes, don't feel like you have to update it. Look at those separately. It will be up to you decide if and how to integrate new features, feature updates, and bug fixes released upstream from you.

[allenbakki]

we have checked the APIs, and they are working fine in local.

[thehabes]

I was able to get the code locally. All tests pass, the app runs, and the endpoints work in my Talend API as expected. AI reviews noted that this is a clean sync. This should be a good base to work from and can go to your main when you are ready.

Noting that we really want to find a way to stop the CodeQL scans. Those ❌'s are going to get very annoying until you actually want to use them. Please look for a way to do this in your repository/organization settings, and we will look for a way to do it in our repository/organization settings.