Support for benchmarking web sessions#24864
Conversation
a8dc869 to
ed4cb93
Compare
722e8d2 to
715c66a
Compare
00632c5 to
a0e6715
Compare
There was a problem hiding this comment.
This seems to be a lot of repeated auth code from regular tsh versions of the same APIs, but what can I say – we did the same thing in lib/teleterm. I wish I was more proficient in Go to suggest a better alternative off the top of my head.
Do you think any non-benchmark code will ever want to use those web api methods? My assumption is that this will only ever be used in specialized cases such as benchmarking.
From the perspective of someone who regularly dives into the code to answer the question "How does tsh do X?", I think adding those methods directly in lib/client/api.go will make it harder to understand which variant of auth methods should be used for certain scenarios.
What do you think of moving those methods to lib/client/webapi.go with a comment at the top explaining how these methods are different from their regular counterparts and in which scenarios they should be used?
There was a problem hiding this comment.
Do you think any non-benchmark code will ever want to use those web api methods? My assumption is that this will only ever be used in specialized cases such as benchmarking.
I don't anticipate that anything outside of the benchmarks will likely ever need to create web sessions from tsh.
What do you think of moving those methods to lib/client/webapi.go with a comment at the top explaining how these methods are different from their regular counterparts and in which scenarios they should be used?
Our authentication story is unfortunately not very uniform, see #20343 for more detail. There isn't much fundamentally different between WebLoginFunc implementations and SSHLoginFunc implementations. They both interact with the web api to authenticate the user, the only difference being that the former results in a web session being created and returned via a cookie. I don't know if lib/client/webapi.go would be a better place than lib/client/api.go for either of these implementations to exist, it would probably make sense for them both to exist in a web api client and not something implemented on TeleportClient. We do have api/client/webclient which exists for that purpose but its quite limited in functionality.
795deec to
060b3dd
Compare
Adds `tsh bench web ssh` to allow benchmarking ssh sessions that are created via the web api. To prevent import cycles between `lib/web` and `lib/client` the cookie implementation in `lib/web/cookie.go` was moved into its own package `lib/web/session`. There is curerntly no support for SSO users - adding a local server to handle the login was out of scope and can be added in the future.
060b3dd to
9e26a36
Compare
#24864 added a dependency of lib/web into tsh which broke windows tsh builds because lib/web transiently depends on lib/srv which has linux specific code. This shuffles around a few things so that lib/web is no longer importing lib/srv at all by: - Indirectly using the srv.SessionController to apply session control for web ssh sessions - Moving the common reversetunnel interfaces into reversetunnelclient since lib/reversetunnel imports lib/srv/forward which imports lib/srv. - Directly converting mysql client errors in the connection tester instead of calling a common function.
#24864 added a dependency of lib/web into tsh which broke windows tsh builds because lib/web transiently depends on lib/srv which has linux specific code. This shuffles around a few things so that lib/web is no longer importing lib/srv at all by: - Indirectly using the srv.SessionController to apply session control for web ssh sessions - Moving the common reversetunnel interfaces into reversetunnelclient since lib/reversetunnel imports lib/srv/forward which imports lib/srv. - Directly converting mysql client errors in the connection tester instead of calling a common function.
Adds
tsh bench web sshto allow benchmarking ssh sessions that are created via the web api. To prevent import cycles betweenlib/webandlib/clientthe cookie implementation inlib/web/cookie.gowas moved into its own packagelib/web/session. There is curerntly no support for SSO users - adding a local server to handle the login was out of scope and can be added in the future.