-
Notifications
You must be signed in to change notification settings - Fork 70
[BK-SUPPORT-PART-1] Separate HTTP client and admin client #132
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
Conversation
--- Master Issue: streamnative#127 *Motivation* Pulsarctl needs to support bookie client API, and will use the same HTTP client to request a different server. So we need to separate the HTTP client to make the different admin client request to different servers. *Modifications* - separate the HTTP client from admin client
|
@sijie @wolfstudy PTAL. Thanks. |
4436927 to
c760010
Compare
|
@sijie @wolfstudy PTAL. Thanks |
1 similar comment
|
@sijie @wolfstudy PTAL. Thanks |
|
@sijie @wolfstudy PTAL. Thanks |
pkg/auth/tls.go
Outdated
| return &cert, err | ||
| } | ||
|
|
||
| func (p *TLSAuthProvider) AddAuthParams(client *http.Client, req *http.Request) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic here is not adding auth params. You are initializing a tls transport. I don't think we should call it AddAuthParams.
Also req is not used in this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Java client implementation already provides a good abstraction for different type of authentication implementation. Please check them out.
I don't think the abstraction here is a good abstraction.
-
initializing a transport should be done during initializing auth provider. we should not do it in a method that will be called for each request. You can try avoid initializing transport each time this method is called, by adding a check logic. It is a hack. but the abstraction is wrong.
-
for a method that will be called for each request,
http.clientis not needed. The java client already provides a good abstraction.
/**
* For mutual authentication, This method use passed in `data` to evaluate and challenge,
* then returns null if authentication has completed;
* returns authenticated data back to server side, if authentication has not completed.
*
* <p>Mainly used for mutual authentication like sasl.
*/
default AuthData authenticate(AuthData data) throws AuthenticationException {
byte[] bytes = (hasDataFromCommand() ? this.getCommandData() : "").getBytes(UTF_8);
return AuthData.of(bytes);
}
you can just add a method authenticate(req *http.Request) (*http.Request) in the auth provider. It is a clear abstraction.
|
@sijie I update the auth implementation. The TLS already init when the HTTP client created. But when users using the token to authenticate, we need to add the header to the HTTP requests. So I provide a new method Please take a look when you have time. Thanks. |
…ve/pulsarctl#132) Master Issue: streamnative/pulsarctl#127 *Motivation* Pulsarctl needs to support bookie client API, and will use the same HTTP client to request a different server. So we need to separate the HTTP client to make the different admin client request to different servers. *Modifications* - separate the HTTP client from admin client
…ve/pulsarctl#132) Master Issue: streamnative/pulsarctl#127 *Motivation* Pulsarctl needs to support bookie client API, and will use the same HTTP client to request a different server. So we need to separate the HTTP client to make the different admin client request to different servers. *Modifications* - separate the HTTP client from admin client
Master Issue: #127
Motivation
Pulsarctl needs to support bookie client API, and will use the
same HTTP client to request a different server. So we need to
separate the HTTP client to make the different admin client request
to different servers.
Modifications