Fine frontend 2 08 2025

[marcor2742]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The best approach is to remove or sanitize the logging of sensitive credential information. For OAuth providers, instead of dumping or partially printing client IDs, only log that a config is present or mask all but a tiny part (if strictly necessary for debugging), or ideally avoid logging the value at all.

Change needed:

• In Back-End/login/my_login/views.py, specifically on line 219, remove or redact the output that includes the actual value of provider_config['client_id'].
• Option 1 (most secure): Log only the presence or length/obscure the value (e.g., log length or a fixed string).
• Option 2 (if absolutely necessary for debugging): Mask all but the last 2 characters (***IDxx) and note that this is a partial value.
• Since this is a debug log for a specific provider and not essential for normal operation, it's best just to log the presence, not the value.

No new methods or imports are necessary.
Simply modify (or comment out) the offending logging statement to remove value exposure.

---

To fix this issue, you should either completely remove the logging of the token_url or restrict such logging to a development/debug environment only. The safest and simplest method is to remove or sanitize the log entry to avoid outputting sensitive or internal configuration data. In this case, you can replace the log statement on line 221 with a generic message indicating that the token URL is set, without revealing the actual URL. If you need to log such information, do so only if an environment variable (like DEBUG) is set, and ideally mask the output. This change should be made in Back-End/login/my_login/views.py, around line 221.

No additional imports or new methods are needed; just modify or remove the logging line.

---

To mitigate the risk of clear-text logging of sensitive data, the best approach is to ensure that sensitive values—such as redirect URIs—are not logged. In this snippet, the intent seems to be a debug statement for "42" OAuth configuration; logging whether the redirect URI is present (or its domain/endpoint, if less-sensitive) could provide sufficient debug info without exposing its full value. Alternatively, the field can be fully masked/obscured.

Recommended fix:

• On line 222 of Back-End/login/my_login/views.py, replace the log statement:

  logger.info(f"🔧 42 Config - Redirect URI: {provider_config['redirect_uri']}")
  

  with a non-revealing alternative, such as:

  logger.info("🔧 42 Config - Redirect URI present: %s", bool(provider_config.get('redirect_uri')))
  

  or, if useful, log just the domain using urllib.parse.urlparse, after importing that at the top if not already present.

What is needed:

• Change the log message to avoid logging the full URI.
• Adjust or add imports only if you show code that extracts domains, but the simplest solution just logs presence.

---

To resolve this, we should avoid logging the potentially sensitive or tainted value of provider_config['token_url'] directly. Instead, log only a generic message indicating a token request is being made, or (if helpful for debugging) log that the token request is being made for OAuth provider <provider> without showing the (taintable) endpoint. If logging the URL is absolutely necessary from an operational point of view, the code must sanitize it thoroughly or ensure it's never user-controlled, but here the best fix is simply to redact the value entirely.

Edit only the log line at line 254 in Back-End/login/my_login/views.py, replacing it with a sanitized/safe log message.

---

The best fix is to prevent the logging of the full token response text, as it often contains sensitive information. Instead, log only non-sensitive metadata such as the status code and headers (headers can still have sensitive information, be cautious). If you need to log the body for debugging, redact/restrict it, or include only safe fields. All changes should be applied to Back-End/login/my_login/views.py, specifically replacing or removing the line:

logger.info(f"Token response text: {token_response.text}")

with a line that does not log sensitive data. If some information from the response must be logged for diagnostics, only log non-sensitive details—otherwise, remove or comment out the line.

No new methods or imports are required, as the logger is already present.

Sensitive information such as OAuth2 token endpoint responses should never be logged in cleartext, especially on error, since they may contain access tokens or secrets. The best way to resolve this is to redact or completely omit the potentially sensitive token_response.text. Instead, only log the HTTP status code, provider name, or a generic error indication. This preserves needed debugging without risking disclosure. Specifically, in Back-End/login/my_login/views.py, on line 272, change the log message to exclude token_response.text, perhaps replacing it with a static [REDACTED] notice.

To fix the problem, avoid logging the entire contents of user_info_response.text when reporting failures of the user info request. Instead, log only safe, non-sensitive metadata (e.g., just the status code or a high-level error indicator), or a generic message. If it is necessary to retain some debugging information about the error, consider truncating the message, or stripping out potentially sensitive elements of the body (like email, tokens, password fields, etc.), but the most robust solution is to avoid logging the body altogether.

Specifically:

• In Back-End/login/my_login/views.py, on line 289, change

  logger.error(f'User info request failed: {user_info_response.text}')

  to something like

  logger.error(f'User info request failed with status {user_info_response.status_code}')

• Optionally, you may include user_info_response.reason or log headers if required, but do not log the full body.
• No new imports are needed.

Only this one line in Back-End/login/my_login/views.py needs to be adjusted.

---

The fix should ensure that sensitive information is not logged. The best approach here is to avoid logging the entire user_info dictionary and instead log only non-sensitive attributes (for example, the user's email and username, if present). If more detailed debugging info is needed, log only explicit, non-sensitive fields that the code expects.

Detailed Fix Steps:

• Update line 293 in Back-End/login/my_login/views.py to only log relevant, non-sensitive attributes from user_info, e.g., email and username (or similar name fields).
• If a more generic solution is needed (for future extension), implement a helper function to redact sensitive fields from dictionaries before logging.
• No changes to imports are required unless a helper function is introduced; in this fix, the logging call is simply updated.

---

To fix the problem, the log message should avoid including the api_key value in clear text.
Instead, the log can record the event ("Invalid API key attempt") and relevant context such as the request path, but should mask, omit, or truncate the API key.
Best practice is to not include any sensitive value, but if traceability requires, you may include only a short hash/fingerprint or the last few characters (e.g., api_key[-4:]).
For this case, remove api_key from the log message, or, if helpful for investigation, log a minimal/non-sensitive fingerprint instead (e.g., "ending with ..."). No significant changes or additional imports are needed—just a change to the log string on line 33.

The best way to fix this issue is to avoid logging the value of the API key itself. Logs should not contain any sensitive values, like API keys, passwords, or tokens. Instead, log an event saying that there was an invalid API key attempt, optionally including non-sensitive data, such as the source IP address or request path if needed for troubleshooting (as long as that information itself does not contain sensitive data).
The fix is to replace the line:

logger.warning(f"Invalid API key attempt: {api_key}")

with:

logger.warning("Invalid API key attempt.")

If further detail is desired for traceability, you can log the request's path or remote address by using attributes like request.path or request.META.get('REMOTE_ADDR'), as long as these are not considered sensitive in your application context.
No new imports or method definitions are needed.

The best way to fix the problem is to ensure that untrusted user input (such as opponentName) is escaped for HTML context before being interpolated into a template string that sets innerHTML. This prevents malicious HTML or JavaScript from being executed.

To keep functionality unchanged, we should define a small utility function (for example, escapeHTML) within the file to encode special characters (&, <, >, ", ', /). We should then use this function for every interpolation of opponentName inside the template literal. All other code should remain unchanged, and the escape function should be added only in the relevant file.

Specifically, in file Front-End/public/pong/multiplayer/multiplayerPong.js:

• Add the escapeHTML function near the top or just inside renderMultiplayerPong (but outside the template literal).
• Before the template, call const safeOpponentName = escapeHTML(opponentName);
• Use ${safeOpponentName} instead of ${opponentName} for all interpolations in the template literal (lines 54, 67, 84).
  This ensures that user-controlled content cannot break out of its intended context or inject scripts.

No new packages are required for this standard HTML escaping step.