support multiple subjects in oidc ping #4475
Conversation
RobKenis
force-pushed
the
feature/support-multiple-oidc-clients
branch
from
54259a8
to
98658a9
Compare
|
I think it may be a bug, I test your code and find some RFC doc, your changes may be correct. In a machine-to-machine (M2M) authentication scenario, different clients typically have different subjects because each client usually represents a distinct application or service. |
|
You need to sort packages to pass CI. @RobKenis |
|
The CI errors in the pull request are due to issues found by
To fix these errors, you need to:
You can use the following commands to fix the issues: gci write --skip-generated -s standard -s default -s prefix(github.com/fatedier/frp/) ./path/to/your/files
gofumpt -w ./path/to/your/filesAfter making these changes, commit the updates and push them to your branch to re-run the CI checks. |
Validate the subject in an oidc ping against a list of logged in subjects. This resolves the issue that multiple connected FRP clients with different OIDC clients result in a failing ping. The ping would fail because the subject in memory would be the value of the last logged in FRPC. This change also changes the constructor of OidcAuthVerifier to take a TokenVerifier interface. This will not change production behavior, but makes testing easier because we can inject a mock verifier during testing. Resolves: fatedier#4466
RobKenis
force-pushed
the
feature/support-multiple-oidc-clients
branch
from
98658a9
to
d082976
Compare
|
@blizard863 I have updated the commit after formatting the code |
* https://github.com/fatedier/frp: support multiple subjects in oidc ping (fatedier#4475)
|
@fatedier @blizard863 |
Validate the subject in an oidc ping against a list of logged in subjects.
This resolves the issue that multiple connected FRP clients with different OIDC clients result in a failing ping. The ping would fail because the subject in memory would be the value of the last logged in FRPC.
This change also changes the constructor of OidcAuthVerifier to take a TokenVerifier interface. This will not change production behavior, but makes testing easier because we can inject a mock verifier during testing.
Resolves: #4466