Feat[MQB]: Add Authenticator and InitialConnectionContext #1004
Conversation
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
emelialei88
force-pushed
the
authn/change-negotiator
branch
from
0816869 to
788d0eb
Compare
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
emelialei88
force-pushed
the
authn/change-negotiator
branch
from
d2c4c40 to
ea2450d
Compare
Signed-off-by: Emelia Lei <[email protected]>
Signed-off-by: Emelia Lei <[email protected]>
dorjesinpo
left a comment
dorjesinpo
left a comment
There was a problem hiding this comment.
interim review.
we have pairs of the following:
decodeInitialConnectionMessage,
scheduleRead,
readCallback
readBlob,
processBlob,
complete
... in both InitialConnectionHandler and InitialConnectionContext.
The point of FSM-like state management is that everything happens in handleEvent and there is only one place where we call complete
Otherwise, we can't rely on controlling actions by the state
Is it possible to engage handleEvent immediately in InitialConnectionHandler::handleInitialConnection and call InitialConnectionContext::complete from handleEvent only.
We seem to have InitialConnectionContext::handleInitialConnection but we call InitialConnectionHandler::handleInitialConnection instead which does not seem to support auth?
| this, | ||
| initialConnectionContext, | ||
| context_wp, | ||
| channel, |
There was a problem hiding this comment.
The comment below is unclear. What mutex is meant by "we can't have mutex?
| } | ||
|
|
||
| if (rc != rc_SUCCESS || d_state == InitialConnectionState::e_NEGOTIATED) { | ||
| BALL_LOG_INFO << "Finished initial connection with rc = " << rc |
There was a problem hiding this comment.
if rc != rc_SUCCESS then d_state can remain InitialConnectionState::e_NEGOTIATED. Probably, not a problem since the object is about to get destructed
| context)); | ||
|
|
||
| // Register as observer of the channel to get the 'onClose' | ||
| bsl::weak_ptr<InitialConnectionContext> context_wp = |
There was a problem hiding this comment.
What is the motivation behind the use of weak_ptr?
|
|
||
| // For anonymous authentication, skip sending the response and proceed | ||
| // directly to the next negotiation step. | ||
| if (isDefaultAuthn) { |
There was a problem hiding this comment.
minor, if isReauthn, there is no need for authenticationResponse
| bslmt::LockGuard<bslmt::Mutex> guard(&d_mutex); // LOCKED | ||
|
|
||
| if (d_state != AuthenticationState::e_AUTHENTICATING) { | ||
| errorDescription << "State not AUTHENTICATING (was " << d_state << ")"; |
3 participants
This PR introduces several refactors and preparations for upcoming authentication support:
Authenticatorclass to encapsulate authentication logic.InitialConnectionHandlertoInitialConnectionContext. Note thatInitialConnectionHandlerwill be deprecated and removed in a future update.At this stage,
TcpSessionFactorystill relies onInitialConnectionHandlerfor negotiation, whileInitialConnectionContextprimarily serves as a data holder. Authentication logic has not yet been integrated into the broker. When we are ready,InitialConnectionHandler::handleInitialConnectioncalled inTcpSessionFactorywill be replaced byInitialConnectionContext::handleInitialConnectionas the entrance to initial connection.