-
Notifications
You must be signed in to change notification settings - Fork 1
Added column for TDAMM tags #1174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
…rough an exception Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…rough an exception Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…-implement-ml-tags-frontend-in-cosmos
The green tags have a 'manual' source and the blue tags have the 'ml' source. The tooltip displays the full form of the tag on hover. Test videos:
Item(s) that are a work in progress:
|
Needs to be updated to leverage patterns for the TDAMM tags instead of writing to the database directly. |
…-implement-ml-tags-frontend-in-cosmos
…-implement-ml-tags-frontend-in-cosmos
return Response({"status": "success"}) | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Stack trace information
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 2 months ago
To fix the problem, we need to ensure that the detailed error information is not exposed to the end user. Instead, we should log the detailed error message on the server side and return a generic error message to the user. This can be achieved by modifying the response on line 490 to remove the detailed exception message and replace it with a generic message.
-
Copy modified line R490
@@ -489,3 +489,3 @@ | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) | ||
return Response({"error": "An internal error has occurred."}, status=500) | ||
|
return Response({"status": "success"}) | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Stack trace information
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 2 months ago
To fix the problem, we need to ensure that detailed error messages are logged on the server while returning a generic error message to the user. This can be achieved by modifying the exception handling block to log the detailed error message using the logger
and returning a generic error message in the response.
- Modify the exception handling block in the
remove_tag
method to log the detailed error message. - Return a generic error message to the user instead of the detailed exception message.
-
Copy modified lines R652-R653
@@ -651,4 +651,4 @@ | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) | ||
logger.error(f"Error occurred: {str(e)}", exc_info=True) | ||
return Response({"error": "An internal error has occurred. Please try again later."}, status=500) | ||
|
return Response({"status": "success"}) | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Stack trace information
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 2 months ago
To fix the problem, we need to ensure that the detailed error information is not exposed to the end user. Instead, we should log the detailed error message on the server and return a generic error message to the user. This can be achieved by modifying the exception handling block to log the error and return a generic message.
- Modify the exception handling block in the
add_tag
method to log the detailed error message and return a generic error message. - Ensure that the logging captures the necessary details for debugging purposes.
-
Copy modified lines R888-R889
@@ -887,4 +887,4 @@ | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) | ||
logger.error(f"Error occurred: {str(e)}", exc_info=True) | ||
return Response({"error": "An internal error has occurred"}, status=500) | ||
|
return Response({"status": "success"}) | ||
except Exception as e: | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Stack trace information
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 2 months ago
To fix the problem, we need to ensure that the detailed error message is not exposed to the end user. Instead, we should log the detailed error message on the server side and return a generic error message to the user. This can be achieved by modifying the return statement on line 1070 to exclude the exception message.
- Modify the return statement on line 1070 to return a generic error message.
- Ensure that the detailed error message is logged on the server side using the existing
logger.error
statement.
-
Copy modified line R1070
@@ -1069,3 +1069,3 @@ | ||
logger.error(f"Error occurred: {str(e)}") | ||
return Response({"error": f"An internal error has occurred: {str(e)}"}, status=500) | ||
return Response({"error": "An internal error has occurred"}, status=500) | ||
|
No description provided.