Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the application's logging and telemetry capabilities by introducing a robust audit logging system. It focuses on ensuring data privacy and compliance through new utilities for IP address validation, masking, and sensitive metadata redaction. The changes integrate these features into a structured event emission mechanism, allowing for detailed tracking of user actions and system events across various storage backends, supported by extensive unit tests. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive audit logging feature across various storage providers (Azure, GCS, S3, Local). It adds structured logging for audit events, including event details, user information, and sanitized metadata like IP addresses. The changes include new utility functions for IP validation and sanitization, along with extensive unit tests for the new functionality.
My review has identified a critical issue in the IP address sanitization logic that could lead to invalid data in audit logs, and a high-severity issue with the S3 log file naming strategy that would be inefficient and costly. I've provided suggestions to fix both.
mmattu-wd
left a comment
There was a problem hiding this comment.
Still need to test the whole flow but left some comments
| await queryRunner.manager.save(User, user) | ||
|
|
||
| // Step 6: Cancel Stripe Subscription | ||
| await this.identityManager.cancelSubscription(organizaiton.subscriptionId) |
There was a problem hiding this comment.
should we move this after the commitTransaction? If for whatever reason the database doesn't commit, there is a case in which the user stays active without a subscription anymore
There was a problem hiding this comment.
Why we didnt have try catch finally with rollbackTransaction and release same as other function at the top?
| const updateAdditionalSeatsApi = useApi(userApi.updateAdditionalSeats) | ||
| const getCurrentUsageApi = useApi(userApi.getCurrentUsage) | ||
| const logoutApi = useApi(accountApi.logout) | ||
| const deleteAccountApi = useApi(accountApi.deleteAccount) |
There was a problem hiding this comment.
should we confirm with a one time passcode or re-entering their password? Is there a chance an attacker can hijack a session and delete someone else's account?
There was a problem hiding this comment.
for sso (google,github) login there isnt any passwords. from the standup we were thinking of something like a confirmation sentence: permanently delete or smtg like that
There was a problem hiding this comment.
Ohh I see! I see google has something for this where you trigger OAuth for sensitive actions prompt=consent. But github does not, we'd have to revoke their OAuth and re-trigger it which isn't ideal.
The only other option would be a OTP sent to the email
| result: TelemetryEventResult | ||
| metadata?: Record<string, any> | ||
| } | ||
| export interface TelemetryEventOutput { |
There was a problem hiding this comment.
There are some fields that currently not compatible with MALT. I will add these to the google doc as we will likely have to pull them from headers or something
|
|
||
| auditLogger.log({ level: 'info', message: event.eventType, ...event }) | ||
| } catch (error) { | ||
| logger.error(`Failed to emit event: ${error}`) |
There was a problem hiding this comment.
When an event fails to emit, should we add it to a queue to be retried? Not an issue rn, but for MALT if we're making http requests, it can become an issue
|
|
||
| for (const key of Object.keys(sanitized)) { | ||
| const lowerKey = key.toLowerCase() | ||
| if (sensitiveFields.some((field) => lowerKey.includes(field))) { |
There was a problem hiding this comment.
this would only look 1 level into the object. Is there any chance data like this gets emitted?:
{
"configuration": {
"apiKey": "someapikey"
}
}
if not we should maybe update the metadata type to be something like Record<string, string | number>. So if we do try logging and object ts catches it, this can be circumvented with any but 🤷 . As it stands right now the above metadata would pass and log the value
| await queryRunner.commitTransaction() | ||
|
|
||
| // Step 7: Delete Organization Folder from Storage | ||
| await removeFolderFromStorage(organizaiton.id) |
There was a problem hiding this comment.
if this throws an error the account would be removed but we wouldn't have emitted an event

FLOWISE-39