Conversation
![hound[bot]](https://avatars.githubusercontent.com/in/3598?s=60&v=4){kind=small}
| @@ -0,0 +1 @@ | |||
| export { default as CommentSection } from './CommentSection.svelte'; | |||
There was a problem hiding this comment.
'export' is only available in ES6 (use 'esversion: 6').
| export function getOptionStyle(value, options) { | ||
| const option = options.find((o) => o.value === value); | ||
| return option?.color ?? 'bg-gray-100 text-gray-600'; | ||
| return option?.color ?? 'bg-[var(--surface-sunken)] text-[var(--text-secondary)]'; |
There was a problem hiding this comment.
Expected ':' and instead saw 'color'.
Expected an assignment or function call and instead saw an expression.
Expected an identifier and instead saw '.'.
Expected an identifier and instead saw '?'.
Expected an operator and instead saw '?'.
Missing semicolon.
|
Important Review skippedToo many files! 14 files out of 164 files are above the max files limit of 150. You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR appears to be an initial milestone ("M1") for setting up a mobile application project structure with comprehensive documentation for a SalesPro CRM system. The changes include iOS Flutter configuration files, extensive documentation for design systems, technical specifications, UI components, and detailed route specifications for both mobile and web implementations.
Changes:
- Added Flutter iOS configuration files (Release.xcconfig, Debug.xcconfig, AppFrameworkInfo.plist, .gitignore)
- Added comprehensive documentation covering design systems, technical specifications, API endpoints, data models, and screen-by-screen implementation guides
- Added Android Gradle wrapper configuration
Reviewed changes
Copilot reviewed 87 out of 200 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| mobile/ios/Flutter/*.xcconfig | Flutter build configuration for iOS |
| mobile/ios/Flutter/AppFrameworkInfo.plist | iOS app framework metadata |
| mobile/ios/.gitignore | iOS-specific ignore patterns |
| mobile/docs/*.md | Design system, technical specs, and README documentation |
| mobile/docs/routes/*.md | Detailed specifications for 12 app screens |
| mobile/docs/components/ui-components.md | Reusable UI component specifications |
| mobile/devtools_options.yaml | Flutter DevTools configuration |
| mobile/android/gradle/wrapper/gradle-wrapper.properties | Gradle build system configuration |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| picture = idinfo.get("picture", "") | ||
| except ValueError as e: | ||
| return Response( | ||
| {"error": f"Invalid token: {str(e)}"}, |
Check warning
Code scanning / CodeQL
Information exposure through an exception Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 27 days ago
In general, to fix this issue you should avoid returning raw exception messages to the client. Instead, log the detailed error message (and optionally the stack trace) on the server, and send a generic, non-sensitive error message in the HTTP response. This preserves debuggability without exposing internal details or third‑party library messages.
For this specific code, the best minimal fix is:
- Keep the
try/except ValueError as e:block as is structurally. - Inside the
except, add server-side logging of the exception (using Python’s standardloggingmodule, which is already widely used and does not change existing functionality). - Replace
{"error": f"Invalid token: {str(e)}"}with a generic message such as{"error": "Invalid token"}so the client no longer sees the raw exception text.
Concretely, in backend/common/views/auth_views.py:
- Add
import loggingat the top alongside the other imports. - In the
except ValueError as e:block inGoogleIdTokenView.post, log the exception usinglogging.exception(orlogging.getLogger(__name__).exception) with a clear message, then return a generic error payload.
No behavior other than the specific error message content is changed: the status code remains 400, and the control flow stays identical.
| @@ -1,6 +1,7 @@ | ||
| import json | ||
| import secrets | ||
|
|
||
| import logging | ||
| import requests | ||
| from django.conf import settings | ||
| from django.contrib.auth.hashers import make_password | ||
| @@ -193,8 +194,9 @@ | ||
| email = idinfo.get("email") | ||
| picture = idinfo.get("picture", "") | ||
| except ValueError as e: | ||
| logging.exception("Failed to verify Google ID token") | ||
| return Response( | ||
| {"error": f"Invalid token: {str(e)}"}, | ||
| {"error": "Invalid token"}, | ||
| status=status.HTTP_400_BAD_REQUEST, | ||
| ) | ||
|
|
1 participant
No description provided.