-
Notifications
You must be signed in to change notification settings - Fork 300
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
Escape pipe character for injected users #5175
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: shikharj05 <[email protected]>
Signed-off-by: shikharj05 <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5175 +/- ##
==========================================
- Coverage 71.68% 71.64% -0.04%
==========================================
Files 337 337
Lines 22785 22788 +3
Branches 3605 3605
==========================================
- Hits 16333 16327 -6
- Misses 4651 4655 +4
- Partials 1801 1806 +5
🚀 New features to boost your workflow:
|
Do we know where the error message noted in #2756 comes from?
I do not see it touched in the PR, so I would guess that the error still persists. |
This error is specifically from AOS. The actual issue reported mentions usage of usage of Cognito with Amazon OpenSearch Service (AOS). |
Thank you for the PR @shikharj05! The user's reporting the issue have only mentioned a problem with usernames in certain SSO providers. Do you think we should limit this change to username and add logic to forbid it in other fields like roles and backend roles or should we do a blanket escape for all fields? |
IMO, it's better to escape all fields like roles, tenants, etc to be consistent and prevent future issues in the same area. |
Description
Escape pipe while setting UserInfo in ThreadContext
Common-utils PR- opensearch-project/common-utils#801
Bug fix
Allow OIDC use-cases where username contain pipes.
usernames, roles & tenants will escape pipe character if present.
Issues Resolved
#2756
Is this a backport? If so, please add backport PR # and/or commits #, and remove
backport-failed
label from the original PR.Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.