Fixed issues with OIDC users and credentials, with some small QOL fixes
Update Log:
Fixed issue where OIDC users logging out would reset passwords/keys for credentials
Changed NGINX to forward the real client IP
Added sidebar persistence (closing either sidebar persists across refresh)
Forced password for SSH
Fixed issues with OIDC users and credentials, with some small QOL fixes
Update Log:
- Fixed issue where OIDC users logging out would reset passwords/keys for credentials
- Changed NGINX to forward the real client IP
- Added sidebar persistence (closing either sidebar persists across refresh)
- Forced password for SSH
Hello @LukeGus, 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 delivers a maintenance update, version 1.7.2, focusing on critical bug fixes and quality-of-life improvements. Key issues addressed include preventing OIDC user credential resets upon logout and ensuring NGINX accurately forwards client IP addresses. Additionally, user experience is enhanced through the persistence of sidebar states and more robust file deletion confirmations.
Highlights
OIDC User Credential Fixes: Resolved an issue where OIDC users logging out would inadvertently reset their stored passwords or keys for credentials, ensuring data integrity.
NGINX Real IP Forwarding: Configured NGINX to correctly forward the real client IP address, which improves logging accuracy and can be crucial for security and analytics.
Sidebar Persistence: Implemented functionality to persist the open/closed state of both the left sidebar and the top navigation bar across page refreshes, enhancing user experience.
Forced SSH Password for Password Auth: Added validation to ensure a password is provided when configuring an SSH host with password authentication, preventing incomplete configurations.
Database Schema Refinement: Standardized database field names for SSH credentials, converting camelCase fields like keyPassword, privateKey, publicKey to snake_case (key_password, private_key, public_key) for consistency.
Enhanced File Deletion Confirmation: Introduced more detailed and context-aware confirmation prompts for deleting files and folders in the File Manager, including warnings about permanent deletion.
Using Gemini Code Assist
The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.
Feature
Command
Description
Code Review
/gemini review
Performs a code review for the current pull request in its current state.
Pull Request Summary
/gemini summary
Provides a summary of the current pull request in its current state.
Comment
@gemini-code-assist
Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help
/gemini help
Displays a list of available commands.
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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.
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.
## Summary of Changes
Hello @LukeGus, I'm Gemini Code Assist[^1]! 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 delivers a maintenance update, version `1.7.2`, focusing on critical bug fixes and quality-of-life improvements. Key issues addressed include preventing OIDC user credential resets upon logout and ensuring NGINX accurately forwards client IP addresses. Additionally, user experience is enhanced through the persistence of sidebar states and more robust file deletion confirmations.
### Highlights
* **OIDC User Credential Fixes**: Resolved an issue where OIDC users logging out would inadvertently reset their stored passwords or keys for credentials, ensuring data integrity.
* **NGINX Real IP Forwarding**: Configured NGINX to correctly forward the real client IP address, which improves logging accuracy and can be crucial for security and analytics.
* **Sidebar Persistence**: Implemented functionality to persist the open/closed state of both the left sidebar and the top navigation bar across page refreshes, enhancing user experience.
* **Forced SSH Password for Password Auth**: Added validation to ensure a password is provided when configuring an SSH host with password authentication, preventing incomplete configurations.
* **Database Schema Refinement**: Standardized database field names for SSH credentials, converting camelCase fields like `keyPassword`, `privateKey`, `publicKey` to snake_case (`key_password`, `private_key`, `public_key`) for consistency.
* **Enhanced File Deletion Confirmation**: Introduced more detailed and context-aware confirmation prompts for deleting files and folders in the File Manager, including warnings about permanent deletion.
<details>
<summary><b>Using Gemini Code Assist</b></summary>
<br>
The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips.
<b>Invoking Gemini</b>
You can request assistance from Gemini at any point by creating a comment using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands on the current page.
Feature | Command | Description
--- | --- | ---
Code Review | `/gemini review` | Performs a code review for the current pull request in its current state.
Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state.
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help | `/gemini help` | Displays a list of available commands.
<b>Customization</b>
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 `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github).
<b>Limitations & Feedback</b>
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: 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](https://google.qualtrics.com/jfe/form/SV_2cyuGuTWsEw84yG).
<b>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](https://cloud.google.com/products/gemini/code-assist).</b>
</details>
[^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).
gemini-code-assist[bot]
(Migrated from github.com)
reviewed 2025-10-07 02:13:58 +11:00
gemini-code-assist[bot]
(Migrated from github.com)
left a comment
Copy Link
Copy Source
Code Review
This pull request introduces several fixes and quality-of-life improvements. The fix for OIDC user data persistence is well-implemented and addresses a critical issue. The addition of sidebar state persistence and improved delete confirmations are great usability enhancements. The database schema changes improve consistency, but this could be taken further. I've identified a few areas for improvement, including a potentially overly restrictive NGINX configuration, some inconsistencies in the database schema naming, a minor redundancy in the code, and a potential bug in the UI's change detection logic for SSH hosts. Overall, this is a solid update.
## Code Review
This pull request introduces several fixes and quality-of-life improvements. The fix for OIDC user data persistence is well-implemented and addresses a critical issue. The addition of sidebar state persistence and improved delete confirmations are great usability enhancements. The database schema changes improve consistency, but this could be taken further. I've identified a few areas for improvement, including a potentially overly restrictive NGINX configuration, some inconsistencies in the database schema naming, a minor redundancy in the code, and a potential bug in the UI's change detection logic for SSH hosts. Overall, this is a solid update.
The set_real_ip_from 127.0.0.1; directive is quite restrictive. If this NGINX instance is running inside a Docker container and is fronted by another proxy (e.g., another container in the same Docker network), the request will likely come from an internal Docker IP, not 127.0.0.1. This would result in the real client IP not being correctly identified.
To make this more robust, consider trusting the common Docker network ranges. This will cover most containerized and local proxy setups. You might want to adjust the CIDR blocks based on your specific Docker network configuration.
set_real_ip_from 172.16.0.0/12; # Default Docker network range
set_real_ip_from 192.168.0.0/16; # Common local network range
set_real_ip_from 10.0.0.0/8; # Another private network range
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;
The `set_real_ip_from 127.0.0.1;` directive is quite restrictive. If this NGINX instance is running inside a Docker container and is fronted by another proxy (e.g., another container in the same Docker network), the request will likely come from an internal Docker IP, not `127.0.0.1`. This would result in the real client IP not being correctly identified.
To make this more robust, consider trusting the common Docker network ranges. This will cover most containerized and local proxy setups. You might want to adjust the CIDR blocks based on your specific Docker network configuration.
```
set_real_ip_from 172.16.0.0/12; # Default Docker network range
set_real_ip_from 192.168.0.0/16; # Common local network range
set_real_ip_from 10.0.0.0/8; # Another private network range
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For;
```
I see you're changing some field names from camelCase to snake_case (e.g., keyPassword to key_password), which is great for consistency with typical SQL naming conventions. However, this change isn't applied consistently across the schema. For example, in the sshData table, fields like userId, authType, credentialId, autostartPassword, and keyType remain in camelCase. The sshCredentials table also has a mix of conventions (keyType, detectedKeyType, usageCount).
This mix of naming conventions can be confusing and lead to bugs. It would be best to choose one convention (preferably snake_case for database schemas) and apply it to all fields for better maintainability.
I see you're changing some field names from camelCase to snake_case (e.g., `keyPassword` to `key_password`), which is great for consistency with typical SQL naming conventions. However, this change isn't applied consistently across the schema. For example, in the `sshData` table, fields like `userId`, `authType`, `credentialId`, `autostartPassword`, and `keyType` remain in camelCase. The `sshCredentials` table also has a mix of conventions (`keyType`, `detectedKeyType`, `usageCount`).
This mix of naming conventions can be confusing and lead to bugs. It would be best to choose one convention (preferably snake_case for database schemas) and apply it to all fields for better maintainability.
This expression credential.key_password || credential.key_password is redundant. It seems to be a leftover from a refactoring. You can simplify it to just credential.key_password.
key_password: credential.key_password,
This expression `credential.key_password || credential.key_password` is redundant. It seems to be a leftover from a refactoring. You can simplify it to just `credential.key_password`.
```suggestion
key_password: credential.key_password,
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixed issues with OIDC users and credentials, with some small QOL fixes
Update Log:
Summary of Changes
Hello @LukeGus, 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 delivers a maintenance update, version
1.7.2, focusing on critical bug fixes and quality-of-life improvements. Key issues addressed include preventing OIDC user credential resets upon logout and ensuring NGINX accurately forwards client IP addresses. Additionally, user experience is enhanced through the persistence of sidebar states and more robust file deletion confirmations.Highlights
keyPassword,privateKey,publicKeyto snake_case (key_password,private_key,public_key) for consistency.Using Gemini Code Assist
The 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
/gemini <command>or@gemini-code-assist <command>. Below is a summary of the supported commands on the current page./gemini review/gemini summary/gemini helpCustomization
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
.gemini/folder in the base of the repository. Detailed instructions can be found here.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.
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩︎
Code Review
This pull request introduces several fixes and quality-of-life improvements. The fix for OIDC user data persistence is well-implemented and addresses a critical issue. The addition of sidebar state persistence and improved delete confirmations are great usability enhancements. The database schema changes improve consistency, but this could be taken further. I've identified a few areas for improvement, including a potentially overly restrictive NGINX configuration, some inconsistencies in the database schema naming, a minor redundancy in the code, and a potential bug in the UI's change detection logic for SSH hosts. Overall, this is a solid update.
@@ -11,2 +11,4 @@client_header_timeout 300s;set_real_ip_from 127.0.0.1;real_ip_header X-Forwarded-For;The
set_real_ip_from 127.0.0.1;directive is quite restrictive. If this NGINX instance is running inside a Docker container and is fronted by another proxy (e.g., another container in the same Docker network), the request will likely come from an internal Docker IP, not127.0.0.1. This would result in the real client IP not being correctly identified.To make this more robust, consider trusting the common Docker network ranges. This will cover most containerized and local proxy setups. You might want to adjust the CIDR blocks based on your specific Docker network configuration.
@@ -49,3 +49,3 @@keyPassword: text("key_password"),key_password: text("key_password"),keyType: text("key_type"),I see you're changing some field names from camelCase to snake_case (e.g.,
keyPasswordtokey_password), which is great for consistency with typical SQL naming conventions. However, this change isn't applied consistently across the schema. For example, in thesshDatatable, fields likeuserId,authType,credentialId,autostartPassword, andkeyTyperemain in camelCase. ThesshCredentialstable also has a mix of conventions (keyType,detectedKeyType,usageCount).This mix of naming conventions can be confusing and lead to bugs. It would be best to choose one convention (preferably snake_case for database schemas) and apply it to all fields for better maintainability.
This expression
credential.key_password || credential.key_passwordis redundant. It seems to be a leftover from a refactoring. You can simplify it to justcredential.key_password.