chore(medcat-trainer): CU-869a4br6j Create a copy of the v1 medcat-trainer in the v1 folder

[alhendrickson]

…ainer in the /v1 folder

To fix the problem, we need to ensure that all occurrences of the meta-characters (&, <, >) are replaced, not just the first. The best way to do this is to use regular expressions with the global (g) flag in the replace method. Specifically, replace replace('&', '&amp') with replace(/&/g, '&'), and similarly for < and >. This change should be made on line 76, within the formattedText computed property. No new imports or methods are needed, as this is standard JavaScript functionality.

To fix the problem, we should ensure that all occurrences of the special characters are replaced, not just the first. The best way to do this is to use regular expressions with the global (g) flag in the replace method. Specifically, we should replace all & with &, all < with <, and all > with >. The order of replacements is important: & should be replaced first to avoid double-escaping the ampersands introduced by the other replacements. The fix should be applied to line 76 in the formattedText computed property in v1/medcat-trainer/webapp/frontend/src/components/common/ClinicalText.vue. No new imports are needed, as this is standard JavaScript functionality.

---

To fix the problem, all occurrences of the special characters should be replaced, not just the first. The best way to do this is to use regular expressions with the global (g) flag in the replace calls. Additionally, the current code incorrectly escapes < as &gt (should be &lt) and both < and > are replaced with &gt, which is not correct. The correct HTML entities are & for &, < for <, and > for >. The fix should use the correct entities and replace all occurrences. This can be done directly in the code shown, within the formattedText computed property in ClinicalText.vue.

No new imports are needed, as this is standard JavaScript functionality.

---

To fix the problem, we need to ensure that any file path constructed from user input is safely contained within the intended directory (MEDIA_ROOT). The best way to do this is to:

1. Use os.path.join to construct the path, rather than string concatenation.
2. Normalize the resulting path using os.path.normpath or os.path.realpath.
3. Check that the normalized path starts with MEDIA_ROOT (after normalizing both).
4. Optionally, use werkzeug.utils.secure_filename to further sanitize the filename portion.

The changes should be made in v1/medcat-trainer/webapp/api/api/data_utils.py:

• Replace the string concatenation for cuis_file_name and ds_file_name with a safe join and normalization.
• Add a check that the resulting path is within MEDIA_ROOT.
• Raise an exception or handle the error if the check fails.

We will need to import os (if not already imported) and, optionally, werkzeug.utils.secure_filename for robust filename sanitization.

---

To fix the problem, we need to ensure that the constructed file path cannot be manipulated by user input to escape the intended directory (MEDIA_ROOT). The best way to do this is to sanitize and validate report_name before using it in the file path. We can use werkzeug.utils.secure_filename to ensure the filename is safe, and then join and normalize the path, checking that it remains within MEDIA_ROOT. This prevents path traversal and other attacks. We should also ensure that the filename does not contain directory separators or other problematic characters.

Steps:

• Import secure_filename from werkzeug.utils.
• Before constructing report_file_path, sanitize report_name using secure_filename.
• Construct the path using os.path.join.
• Normalize the path using os.path.normpath.
• Check that the resulting path starts with MEDIA_ROOT.
• If the check fails, raise an exception or handle the error appropriately.

All changes are to be made in v1/medcat-trainer/webapp/api/api/metrics.py.

---

To fix this problem, the stack trace should not be included in the response sent to the user. Instead, the stack trace should be logged on the server for debugging purposes, and the user should receive a generic error message. This can be achieved by removing the stacktrace field from the response and using Python's logging module to log the stack trace. The fix should be applied to the exception handler in the prepare_documents function in v1/medcat-trainer/webapp/api/api/views.py. If the logging module is not already imported, it should be imported at the top of the file.

---

To fix this issue, we should ensure that any user input interpolated into an HTTP response is properly escaped to prevent XSS. The best way to do this in Django is to use the django.utils.html.escape() function to sanitize the cdb_id before including it in the response. This will convert any HTML special characters in cdb_id to their safe, escaped equivalents, preventing malicious code injection. The fix should be applied directly to line 457 in v1/medcat-trainer/webapp/api/api/views.py, and we need to ensure that escape is imported from django.utils.html.

To fix the problem, we should avoid returning the raw exception message to the client. Instead, return a generic error message, such as "An internal error has occurred." For debugging purposes, log the exception and stack trace on the server side using Python's logging module. This ensures developers can still diagnose issues without exposing sensitive details to users.

Steps:

• In the except Exception as e: block (lines 714-715), replace the response with a generic error message.
• Log the exception and stack trace using the logging module.
• Add an import for logging at the top of the file if not already present.

---

To fix the reflected server-side XSS vulnerability, we should escape the user-supplied report_id before including it in the response. In Django, the recommended way to escape HTML is to use django.utils.html.escape. We should import this function and use it to sanitize report_id in the error message returned by HttpResponseBadRequest. The change should be made in the view_metrics function, specifically on line 810. Additionally, the function should return the response object (i.e., return HttpResponseBadRequest(...)) rather than just calling it, to ensure the error is properly sent to the client.

Required changes:

• Import escape from django.utils.html.
• Use escape(report_id) in the error message on line 810.
• Add return before HttpResponseBadRequest(...) on line 810.

---

To fix this issue, we should ensure that any user-provided data interpolated into an HTTP response is properly escaped or validated. Since report_id is expected to be an integer, the best fix is to explicitly cast it to an integer before using it in the response. This will prevent any malicious input from being injected into the response. If the cast fails, we should return a generic error message without including the user input. The changes should be made in the view_metrics function in v1/medcat-trainer/webapp/api/api/views.py, specifically on lines where report_id is used in an HTTP response.

No new imports are needed, as Python's built-in int() function suffices for type enforcement.

---

To fix the problem, add a permissions block to the workflow file to explicitly set the minimal required permissions for the GITHUB_TOKEN. Since the workflow only checks out code, installs dependencies, runs tests, and builds packages/containers, it does not require any write permissions. The minimal required permission is contents: read, which allows the workflow to read repository contents. This block should be added at the top level of the workflow file (after the name: and before on:), so it applies to all jobs in the workflow. No changes to the jobs or steps are needed.

---

To fix the problem, add a permissions block to the workflow file .github/workflows/medcat-trainer-v1_ci.yml. The block should be placed at the top level, just after the name and before the on key, so that it applies to all jobs in the workflow. The minimal required permission for this workflow is contents: read, as none of the jobs require write access to the repository. No additional imports or definitions are needed; this is a YAML configuration change only.

To fix the problem, add a permissions block to the workflow file to explicitly restrict the GITHUB_TOKEN permissions. The best way to do this is to add the block at the top level of the workflow, so it applies to all jobs unless overridden. In this case, the jobs only need to read repository contents (for checkout), so set contents: read. This change should be made near the top of the file, after the name: and before the on: block. No additional imports or definitions are needed.

To fix the problem, you should add a permissions block to the workflow file. This can be done at the root level (applies to all jobs) or at the job level (for more granular control). Since neither job appears to require write access to repository contents, issues, or pull requests, the minimal permission of contents: read is appropriate. This change should be made at the top level of the workflow file, immediately after the name: and before the on: block, to ensure all jobs inherit these permissions unless overridden. No additional imports or definitions are required.

To fix the problem, add a permissions block to the workflow file to explicitly set the minimum required permissions for the jobs. The best way to do this is to add the permissions key at the top level of the workflow (just after the name and before on), which will apply to all jobs unless overridden. Since the jobs do not appear to require any write access to repository contents, the minimal permission of contents: read is sufficient. No changes to the jobs themselves are necessary.

Steps:

• Insert the following at the top of .github/workflows/medcat-trainer-v1_release.yml, after the name field and before on:

  permissions:
    contents: read

• No additional imports, methods, or definitions are needed.

To fix the problem, add an explicit permissions block to the workflow file. The block should be placed at the top level (applies to all jobs) or at the job level (for each job that does not need write access). Since neither job in this workflow appears to require write access to the repository via the GITHUB_TOKEN, the minimal required permission is contents: read. This should be added near the top of the file, after the name and before or after the on block. No other code changes are needed.

---

[mart-r]

We may want to make a note of the CodeQL issues for the future.

But since they're already in the other one anyway, I don't see it as a priority.