feat(shop): Add enchantment search and display to shop directory

[google-labs-jules]

This change adds the ability to search for enchanted books by their enchantment and displays the enchantment in the shop directory results. The shoppingDirectory view was updated to parse enchantment data, and the API, web view, and Discord command were updated to use this new data.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll acknowledge your comments with a 👀 emoji and then get to work. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

I will automatically address your feedback. For any comments you don't want me to act on, just include (aside).

---

---

For security, I will only act on instructions from the user who triggered this task for this pull request.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

How to, in general terms, fix the problem:

To prevent SQL injection, do not interpolate user-provided data directly into SQL query strings. Instead, use parameterized queries, wherein user input is supplied to the database engine separately from the query string, allowing the database driver to escape or handle the values safely.

Detailed fix for this code:

• In both cases where user input is used (bridgeId and targetServer), rewrite the SQL queries to use placeholders (typically ? for MySQL, or $1, $2 for PostgreSQL).
• Supply the user input as a separate argument to the db.query function, assuming this function follows the standard Node.js database callback pattern (e.g., mysql or mysql2).
• Remove direct interpolation of user input into the query.
• Adjust the getBridge function to accept parameters separately from the query.
• When neither of the parameters is provided, keep the default query (SELECT * FROM bridge;), which does not include user input and thus is safe as-is.

Required changes:

• Update code at lines 17-38 and the code invoking getBridge to use query placeholders and arguments.
• No new package imports are needed if using an SQL database connector with standard support for parameterized queries.
• There is no need to change logic elsewhere in the file; changes are contained in the handler function for /api/bridge/get.

---

The best way to fix this problem is to apply a rate-limiting middleware to the route that performs the database write: the POST /api/bridge/command/add endpoint. This can be achieved by using the express-rate-limit package, which is a well-known and reliable solution for this purpose.

To implement this fix:

• Import the express-rate-limit package at the top of the file.
• Define a rate limiter instance (for example, with reasonable defaults such as 100 requests per 15-minute window).
• Apply the rate limiter middleware to the specific route handler for POST /api/bridge/command/add.

These changes are self-contained and do not affect the existing endpoint functionality, except for limiting the rate of incoming requests to prevent abuse. They must be made in the file api/routes/bridge.js, with the import at the top, limiter definition above the relevant handler, and the middleware added to the route definition itself.

---

To fix the missing rate limiting issue, a rate limiting middleware such as express-rate-limit should be applied to the sensitive endpoint at /api/bridge/command/process.

• Install express-rate-limit if it's not already a project dependency.
• Import express-rate-limit in api/routes/bridge.js.
• Define a suitable rate limiter (e.g., limiting requests to 10 per minute per IP for this endpoint).
• Apply the rate limiter as middleware on the /api/bridge/command/process POST route.
  This can be achieved by modifying the route registration so that the limiter is specified as a second argument before the handler function.

Changes needed:

• Add import for express-rate-limit.
• Add definition of rate limiter configuration above route registration.
• Add the rate limiter as a middleware argument for the /api/bridge/command/process POST route.

---

To generally fix this issue, a rate-limiting middleware should be applied to the /api/bridge/clear POST endpoint to limit the number of requests that can trigger this expensive operation in a given time period. The best way to do this in an Express.js environment is to use the widely adopted express-rate-limit middleware.

Specifically:

• Import express-rate-limit at the top of the file (or require it if using CommonJS).
• Define a rate limiter instance tuned for admin-level sensitive operations (e.g., allow only 3 requests per minute per IP for the /clear endpoint; adjust the rate as needed for the use case).
• Apply this rate limiter as middleware to the app.post(baseEndpoint + "/clear", ...) call.
• Only make code changes in the api/routes/bridge.js file, in the region(s) shown above.

---

To address the problem, we should apply a rate-limiting middleware to the vulnerable route(s). The best method is to use the popular express-rate-limit package. We should import or require this package, configure an appropriate limiter (e.g., 100 requests per 15 minutes, as in the example), and apply it specifically to /api/bridge/server/get (and, optionally, other sensitive endpoints).

As the code uses ES6 imports and defines the routes inside a function, we need to ensure the rate limiter is initialized near the top of the file and then passed as middleware to only the handler for app.get(baseEndpoint + "/server/get", ...).
This can be done by editing api/routes/bridge.js as follows:

• Add an import for express-rate-limit.
• Define a rate limiter (customize limits if needed).
• Use the rate limiter as middleware for the server/get route handler.

---

To fix this problem, you should ensure that user-controlled data (vaultId) is never directly interpolated in SQL strings. Instead, use query parameters or prepared statements supported by the database connector, which will securely embed the user input as a literal value. This can usually be done by changing the query string to use placeholders (e.g., ? for MySQL, $1 for PostgreSQL), and passing the user input as a separate argument to the db.query function.

Specifically, for the code in api/routes/vault.js, in the handler for /api/vault/get, modify the logic:

• When vaultId is present, change the query from string interpolation to use a parameterized query.
• Update the getVault function to accept both the query string and parameter values, and forward them to db.query.
• In the case when vaultId is present, call getVault with the query and the vaultId as a parameter value.
• The default branch (getting all vaults) can remain unchanged.

Assume that db.query follows the common Node.js/MySQL/PG convention: db.query(queryString, paramsArray, callback).

---

To fix this issue, add a rate limiting middleware to the Express route POST /api/vault/create. The recommended approach is to use the widely-adopted package express-rate-limit since it is specifically designed for this purpose. This requires: (1) adding an import (using CommonJS-style require as Express expects, or dynamic import); (2) creating a rate limiter instance with sensible defaults (e.g., maximum 10-20 requests per minute for creation); and (3) applying this middleware to the problematic route (on line 60) so that excessive requests will be rejected automatically. Only minimal changes are needed for this file: a new import, a new limiter definition, and an updated route handler that includes the limiter as the first argument.

To address the missing rate limiting, we should apply a rate-limiting middleware to all the /api/vault endpoints (GET and POST). The best and most standardized solution is to use the express-rate-limit package, which allows configurable request rate limiting. This can be done by importing (requiring) the package, configuring a rate limiter (e.g., max 100 requests per 15 minutes), and then applying it specifically to the baseEndpoint router, or to each route as needed.

Changes to make:

• Import the express-rate-limit package at the top of the file.
• Create a RateLimit instance with desired configuration in the vaultApiRoute function.
• Apply the rate limiter middleware to all app.get and app.post handlers in this file.
• No changes to existing route logic or functionality.

We'll need to:

• Add the required import statement.
• Define and configure the rate limiter INSIDE the exported function (since this is probably loaded per-app).
• Pass the rate limiter as middleware in each route definition (before the handler).

---

To fix this problem, we should ensure that requests to the potentially expensive /api/vault/delete endpoint (as well as potentially the other endpoints for consistency) are rate-limited. The best and least invasive approach is to use the express-rate-limit library, specifically applying a rate limiter middleware to the affected route(s). We need to:

• Add an import for express-rate-limit.
• Create a rate limiting instance, e.g., allowing a reasonable max number of requests (e.g., 10 per minute) on sensitive routes.
• Apply this rate limit only to the /api/vault/delete route handler (using it as middleware on the affected route).

These changes are to be made directly in api/routes/vault.js:

• Insert the import for express-rate-limit at the top.
• Define a limiter (e.g., vaultDeleteLimiter) before the route handlers.
• Add the limiter as middleware to the app.post(baseEndpoint + "/delete", ...) route.

---