diff --git a/.github/ISSUE_TEMPLATE/webtestplan.md b/.github/ISSUE_TEMPLATE/webtestplan.md index 6e71f965f0365..8a3e3f0faa160 100644 --- a/.github/ISSUE_TEMPLATE/webtestplan.md +++ b/.github/ISSUE_TEMPLATE/webtestplan.md @@ -613,7 +613,6 @@ Not available for OSS ## Web Terminal (aka console) -- [ ] Verify that top nav has a user menu (Main and Logout) - [ ] Verify that switching between tabs works with `ctrl+[1...9]` (alt on linux/windows) - Update your user role to `require_session_mfa` and: - [ ] Verify connecting to a ssh node prompts you to tap your registered WebAuthn key @@ -808,16 +807,12 @@ Add the following to enable read access to trusted clusters - Auth methods - Verify that the app supports clusters using different auth settings (`auth_service.authentication` in the cluster config): - - [ ] `type: local`, `second_factor: "off"` - [ ] `type: local`, `second_factor: "otp"` - [ ] Test per-session MFA items listed later in the test plan. - [ ] `type: local`, `second_factor: "webauthn"`, - [ ] Test per-session MFA items listed later in the test plan. - [ ] `type: local`, `second_factor: "webauthn"`, log in passwordlessly with hardware key - [ ] `type: local`, `second_factor: "webauthn"`, log in passwordlessly with touch ID - - [ ] `type: local`, `second_factor: "optional"`, log in without MFA - - [ ] `type: local`, `second_factor: "optional"`, log in with OTP - - [ ] `type: local`, `second_factor: "optional"`, log in with hardware key - [ ] `type: local`, `second_factor: "on"`, log in with OTP - [ ] Test per-session MFA items listed later in the test plan. - [ ] `type: local`, `second_factor: "on"`, log in with hardware key @@ -830,7 +825,6 @@ Add the following to enable read access to trusted clusters parens. Or set up the connectors on a local enterprise cluster following [the guide from our wiki](https://gravitational.slab.com/posts/quick-git-hub-saml-oidc-setup-6dfp292a). - [ ] GitHub (asteroid) - - [ ] local login on a GitHub-enabled cluster - [ ] SAML (platform cluster) - [ ] OIDC (e-demo) - Verify that all items from this section work on: @@ -911,12 +905,11 @@ Add the following to enable read access to trusted clusters - [ ] Check that those connections are removed after you log out of the root cluster that they belong to. - [ ] Verify that reopening a db connection from the connections picker remembers last used port. -- Cluster resources (servers, databases, k8s, apps) +- Cluster resources - [ ] Verify that the app shows the same resources as the Web UI. - [ ] Verify that search is working for the resources list. - [ ] Verify that pagination is working for the resources list. - - [ ] Verify that pagination works in tandem with search, that is verify that search results are - paginated too. + - [ ] Verify that search results are paginated too. - [ ] Verify that you can connect to these resources. - Verify that this works on: - [ ] macOS @@ -1163,25 +1156,18 @@ Add the following to enable read access to trusted clusters - [ ] Verify that Connect asks for relogin when attempting to connect to an app after cert expires. - Be mindful that you need to connect to the app at least once before the cert expires for Connect to properly recognize it as a TCP app. - - Start the app with debug logs on and tail `tshd.log`. Verify that the UI works correctly in the - following scenarios: - - All buth the first point assume that you successfully go through the osascript prompt. - - Close the osascript prompt. - - [ ] The VNet panel shows info about the password prompt being closed. - - Start VNet, then stop it. - - [ ] The VNet panel doesn't show any errors related to VNet being stopped. - - Start VNet, then remove the socket file used for communication with the admin process. It's reported in - `tshd.log` as `Created unix socket for admin subcommand socket:`. - - [ ] The VNet panel shows an unexpected shutdown of VNet and an in-app notification is shown. - - [ ] The admin process cleans up files in `/etc/resolver`. - - Start VNet. While its running, kill the admin process. - - The easiest way to find the PID of the admin process is to open Activity Monitor, View → - All Processes, Hierarchically, search for `tsh` and find tsh running under kernel_task → - authtrampoline → bash → tsh. Then just `sudo kill -s KILL `. - - [ ] The VNet panel shows an unexpected shutdown of VNet and an in-app notification is shown. - - [ ] The admin process _leaves_ files in `/etc/resolver`. However, it's possible to start - VNet again, connect to a TCP app, then shut VNet down and it results in the files being - cleaned up. + - Start VNet, then stop it. + - [ ] Verify that the VNet panel doesn't show any errors related to VNet being stopped. + - Start VNet. While its running, kill the admin process. + - The easiest way to find the PID of the admin process is to open Activity Monitor, View → + All Processes, Hierarchically, search for `tsh` and find tsh running under kernel_task → + launchd → tsh, owned by root. Then just `sudo kill -s KILL `. + - [ ] Verify that the admin process _leaves_ files in `/etc/resolver`. However, it's possible to + start VNet again, connect to a TCP app, then shut VNet down and it results in the files being + cleaned up. + - [ ] Start VNet in a clean macOS VM. Verify that on the first VNet start, macOS shows the prompt + for enabling the background item for tsh.app. Accept it and verify that you can connect to a TCP + app through VNet. - Misc - [ ] Verify that logs are collected for all processes (main, renderer, shared, tshd) under `~/Library/Application\ Support/Teleport\ Connect/logs`.