-
Notifications
You must be signed in to change notification settings - Fork 59
feat(security): implement meta server access controller #655
Conversation
levy5307
commented
Nov 2, 2020
•
edited by foreverneverer
Loading
edited by foreverneverer
|
||
// _client_username is only valid if it is a server rpc_session. | ||
// it represents the name of the corresponding client | ||
std::string _client_username; |
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.
Dont couple the username into rpc_session. Place it into negotiation or somewhere. rpc_session should not
be responsible for any authorization stuff. Use interceptor or other means.
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.
I think it's ok to add a client_username
property for rpc_session. It's a stuff of the session itself, but not provided for security. security is just using it.
It will be a little too complex if we put it into negotiation
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.
No authorization/negotiation then no username. The RPC module should be pure network RPC implementation that can be used in every place whether or not the auth enabled. We must insist open-close principle that prevents such modification to add responsibility to a class.
I will take some time thinking about how to dispose of this variable, if you got no idea then.
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.
OK, but I don't suggest add user_name to negotiation, because in this way we should get the corresponding negotiation for each rpc_session, which will acquire a lock. It will produce low efficiency