Rc to metdata branch

[geofranzi]

No description provided.

In general, to fix this type of issue you either (1) avoid making the cookie persistent (omit Expires so it becomes a session cookie held only in memory), or (2) drastically reduce the lifetime to the minimum necessary (ideally a few minutes) and ensure other security attributes (HttpOnly, Secure, SameSite) are set. For authentication tokens like JWTs, best practice is usually to keep the cookie as a session cookie and control token lifetime inside the token itself.

For this specific snippet, the minimal, behavior‑preserving fix is to stop making the JWT cookie persist for a full day. The safest change is to remove the explicit Expires assignment entirely so the cookie becomes a session cookie. If you still need a short persistence, you could set a much shorter expiry (e.g., AddMinutes(5)), but that changes user experience more; turning it into a session cookie aligns with typical login behavior and still lets the JWT control its own validity. Alongside this, we should explicitly strengthen cookie flags where possible: set HttpOnly = true and Secure = true so the token cannot be read by JavaScript and is only sent over HTTPS. These flags do not change functional behavior from the user’s perspective but significantly harden security.

Concretely, in Console/BExIS.Web.Shell/Controllers/AccountController.cs, in the block where cookieJwt is created (around line 305+), we will:

• Remove the line cookieJwt.Expires = DateTime.Now.AddDays(1);.
• Optionally adjust the comment to reflect that we’re not setting a long‑lived expiry anymore.
• Add cookieJwt.HttpOnly = true; and cookieJwt.Secure = true; to better protect the JWT in transit and at rest.
• Keep existing domain and path settings unchanged.

No new imports or external dependencies are required; HttpCookie.HttpOnly and HttpCookie.Secure are part of System.Web.

In general, to fix an overly broad cookie path, set the cookie’s Path to the actual application path (or a specific subpath that needs the cookie) instead of "/". This limits which parts of the server can receive and potentially access or manipulate that cookie.

In this specific case in Console/BExIS.Web.Shell/Controllers/AccountController.cs, update the cookie’s path assignment on line 313 so it is not hardcoded to "/". The safest, least intrusive change—without changing visible behavior for this application—is to set the path to ASP.NET’s Request.ApplicationPath, which is the root virtual path of the current application. That still allows all controllers/views within this app to receive the cookie but prevents other applications on the same domain (with different virtual roots) from accessing it. We don’t need new imports or methods; we just replace the literal "/" with Request.ApplicationPath ?? "/" to be robust if ApplicationPath is null, preserving current behavior as a fallback.

To fully address the escaping/encoding issue, we need to ensure that the replace call in getReadableComment() removes all backslashes, not just the first. This is done by adding the g (global) flag to the regular expression. No other files or regions need to be changed. No new imports or helper methods are required—just replace /\\/ with /\\/g on line 62. This minimizes side effects while ensuring all unwanted characters are stripped.

---

To fix the problem, add an explicit permissions block that limits the GITHUB_TOKEN to the least privileges needed. This workflow only checks out code, installs tools, runs a read-only analysis, and uploads an artifact. None of these require write access to repo contents, issues, or PRs, so contents: read at either the workflow root or the job level is sufficient.

The best fix with minimal functional impact is to add permissions: contents: read at the job level for the upgrade-check job. This keeps the scope tightly bound to this job and avoids affecting other workflows. Concretely, in .github/workflows/main.yml, insert:

    permissions:
      contents: read

between runs-on: windows-latest (line 10) and steps: (line 12). No additional methods, imports, or definitions are needed.