Merge branch 'main' into main

docs/basics/sso/configuring-sso-in-okta.md

@@ -13,7 +13,7 @@ Sauce Labs app from the Okta catalog supports the following features:
 - [SP-initiated SSO](/basics/sso/logging-in-via-sso/#service-provider-sp-initiated-sso).
 - [IdP-initiated SSO](/basics/sso/logging-in-via-sso/#identity-provider-idp-initiated-sso).
 - [JIT (Just-In-Time) Provisioning](/basics/sso/setting-up-sso/#just-in-time-jit-provisioning).
-- [Big Bang configuration](/basics/sso/setting-up-sso/#enforce-saml-sso-big-bang-configuration).
+- [Big Bang configuration](/basics/sso/setting-up-sso/#enforce-saml-sso---big-bang-configuration).
 
 Complete the following steps to set up SAML SSO integration between Okta and Sauce Labs:
 

docs/basics/sso/migration-from-deprecated-sso.md

@@ -26,7 +26,7 @@ You will have access to the configuration panels of both integrations in the Tea
 | SP-initiated Flow                 | The new SSO supports both [Service Provider (SP) initiated and Identity Provider (IdP) initiated SSO](/basics/sso/logging-in-via-sso), whereas the deprecated SSO only supports IdP-initiated flow.                                                                                                                                                                                                                                                                                                                                                                           |
 | Email Domains                     | Assign your [company email domains](/basics/sso/setting-up-sso/#email-domains) to your SSO integration at Sauce Labs to allow for provisioning of new accounts via SP-initiated flow. <br/><br/> The deprecated SSO does not require email domains as it does not support SP-initiated flow.                                                                                                                                                                                                                                                                                  |
 | JIT Provisioning                  | In the new SSO, JIT (Just-In-Time) provisioning is enabled by default and cannot be disabled. This means that if a user from your Identity Provider (IdP) does not have a Sauce Labs account, one will be automatically created for them. <br/><br/> However, in the deprecated SSO, it was possible to disable this feature. In such cases, it's important to note that users from the IdP who do not have accounts in Sauce Labs will still be able to provision accounts automatically. Keep this in mind during the migration process from deprecated SSO to the new SSO. |
-| Enforce SAML SSO                  | This [setting](/basics/sso/setting-up-sso/#enforce-saml-sso-big-bang-configuration) is also present in the new SSO, but it is common to both the new SSO and the deprecated SSO. When turned on, it allows authentication only via either the new SSO or the deprecated SSO. When turned off, users can also log in via username and password, in addition to SSO authentication.                                                                                                                                                                                                                    |
+| Enforce SAML SSO                  | This [setting](/basics/sso/setting-up-sso/#enforce-saml-sso---big-bang-configuration) is also present in the new SSO, but it is common to both the new SSO and the deprecated SSO. When turned on, it allows authentication only via either the new SSO or the deprecated SSO. When turned off, users can also log in via username and password, in addition to SSO authentication.                                                                                                                                                                                                                    |
 | User Identifier (NameID)          | The [Name ID format](/basics/sso/setting-up-sso/#name-id) must be set to `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` in the new SSO. The value of the attribute NameID in the SAML response must be a valid email address. We do not accept non-email address values, such as usernames or IDs. <br/><br/> The deprecated SSO accepts any value in NameID, such as usernames, email addresses, or other user identifiers.                                                                                                                                        |
 | No Unique Identifier String (UIS) | In the new SSO, there is no need to specify the [Unique Identifier String](/basics/acct-team-mgmt/org-settings/#single-sign-on-settings-deprecated-flow) which was used in the deprecated SSO to generate usernames for new users.<br/><br/>Usernames for accounts provisioned via the new SSO are generated according to the [following pattern](/basics/sso/setting-up-sso/#usernames).                                                                                                                                                                                     |
 | Team Placement                    | New users are provisioned in the [default team](/basics/sso/setting-up-sso/#team-placement) in the new SSO, unlike the deprecated SSO where you can specify a team for new user provisioning.                                                                                                                                                                                                                                                                                                                                                                                 |

docs/basics/sso/setting-up-sso.md

@@ -20,7 +20,7 @@ Sauce Labs supports the following features:
 - [SP-initiated SSO](/basics/sso/logging-in-via-sso/#service-provider-sp-initiated-sso).
 - [IdP-initiated SSO](/basics/sso/logging-in-via-sso/#identity-provider-idp-initiated-sso).
 - [JIT (Just-In-Time) Provisioning](#just-in-time-jit-provisioning).
-- [Force authentication](#enforce-saml-sso-big-bang-configuration).
+- [Force authentication](#enforce-saml-sso---big-bang-configuration).
 
 ## What You'll Need
 

docs/dev/api/connect.md

@@ -75,7 +75,7 @@ curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
 
 ```jsx title="Sample Request"
 curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
---request GET 'https://api.us-east-1.saucelabs.com/rest/v1/jim.smith/tunnels' \
+--request GET 'https://api.us-east-4.saucelabs.com/rest/v1/jim.smith/tunnels' \
 --header 'Content-Type: application/json' | json_pp
 ```
 
@@ -204,7 +204,7 @@ curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
 
 ```jsx title="Sample Request"
 curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
---request GET 'https://api.us-east-1.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8' \
+--request GET 'https://api.us-east-4.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8' \
 --header 'Content-Type: application/json' | json_pp
 ```
 
@@ -314,7 +314,7 @@ curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
 
 ```jsx title="Sample Request"
 curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
---request GET 'https://api.us-east-1.saucelabs.com/rest/v1/public/tunnels/info/versions' | json_pp
+--request GET 'https://api.us-east-4.saucelabs.com/rest/v1/public/tunnels/info/versions' | json_pp
 ```
 
 </TabItem>
@@ -631,7 +631,7 @@ curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
 
 ```jsx title="Sample Request"
 curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
---request GET 'https://api.us-east-1.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8/num_jobs' \
+--request GET 'https://api.us-east-4.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8/num_jobs' \
 --header 'Content-Type: application/json' | json_pp
 ```
 
@@ -721,7 +721,7 @@ curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
 
 ```jsx title="Sample Request"
 curl -u "$SAUCE_USERNAME:$SAUCE_ACCESS_KEY" --location \
---request DELETE 'https://api.us-east-1.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8' \
+--request DELETE 'https://api.us-east-4.saucelabs.com/rest/v1/jim.smith/tunnels/28e7c8133ede4588a891666dd35af1f8' \
 --header 'Content-Type: application/json' | json_pp
 ```
 

docs/dev/cli.md

@@ -17,7 +17,7 @@ hide_table_of_contents: true
 <div>
   <div className="box boxwidetop card">
     <div className="container">
-    <a href="/dev/cli/sauce-connect-5/run"><h3>Sauce Connect Proxy 5 CLI (beta)</h3></a>
+    <a href="/dev/cli/sauce-connect-5/run"><h3>Sauce Connect Proxy 5 CLI </h3></a>
     <p>The CLI tool for deploying Sauce Connect Proxy 5 tunnels.</p>
     </div>
   </div>

docs/dev/cli/sauce-connect-5/run.md

@@ -305,7 +305,7 @@ Setting this to `direct` sends requests to `localhost` directly without using th
 <p><small>| OPTIONAL | STRING | </small></p>
 
 **Description**: Sets domain(s) that do not require TLS resigning. Matching requests will not be TLS re-encrypted. Can be repeated multiple times. See [SSL Certificate Bumping](/secure-connections/sauce-connect/security-authentication#ssl-certificate-bumping) for more information about scenarios in which might want to use this command. See also [formatting domains](#formatting-domains).<br/>
-**Default**: `.*`<br/>
+**Default**: `all`<br/>
 **Environment variable**: `SAUCE_TLS_PASSTHROUGH_DOMAINS`<br/>
 **Shorthand**: `-B`
 

docs/dev/cli/sauce-connect-proxy.md

@@ -8,7 +8,12 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Below is a list of flags to use on your Sauce Connect Proxy command line to specify parameters. Supported versions are indicated in the headers.
+Below is a list of flags to use on your Sauce Connect Proxy v4.x.x command line to specify parameters. Supported versions are indicated in the headers.
+
+:::note
+This is Sauce Connect Version 4 CLI documentation.
+The Sauce Connect Proxy version 5 major release introduced breaking CLI changes. Please refer to [Sauce Connect Proxy 5 CLI Reference](/dev/cli/sauce-connect-5/run/) for details.
+:::
 
 ## What You'll Need
 

docs/dev/cli/saucectl/run.md

@@ -87,6 +87,11 @@ Execute tests according to the environment, framework, and test suite specificat
      <td><span className="t-cli">-h</span></td>
      <td>Usage information for the <code>run</code> command.</td>
     </tr>
+    <tr>
+     <td><span className="t-cli"><a href="#--help">--live-logs</a></span></td>
+     <td></td>
+     <td>Tail the live log output from a running Sauce Orchestrate container.</td>
+    </tr>
     <tr>
      <td><span className="t-cli"><a href="#--no-color">--no-color</a></span></td>
      <td></td>
@@ -366,6 +371,19 @@ Usage information for the `run` command.
 
 </div>
 
+### <span className="cli">--live-logs</span>
+
+<div className="cli-desc">
+<p><small>| OPTIONAL | BOOLEAN | <span className="sauceGreen">Sauce Orchestrate Only</span></small></p>
+
+Tail the live log output from a running Sauce Orchestrate container.
+
+```bash
+saucectl run --live-logs
+```
+
+</div>
+
 ### <span className="cli">--no-color</span>
 
 <div className="cli-desc">

docs/error-reporting/advanced/custom-symbol-server.md

@@ -14,9 +14,11 @@ Backtrace integrations using minidumps require symbol files to generate valuable
 To meet Backtrace's requirements, the custom symbol server must:
 
 - Follow Microsoft's standard symbol structure (that is, `<url>/<object_name>/<debug_id>/<file>`).
-- Use tools like Windows symstore to generate files in the required structure.
+  - Use tools like Windows symstore to generate files in the required structure.
 - Have a web frontend to serve the files via HTTP(S). Popular options include nginx, AWS, and Google Cloud buckets.
 - Allow your Backtrace instance to access the server (firewall and network rules may need adjustments).
+- Any file compression must utilize the CAB (Cabinet) compression mechanism. Backtrace does not support any other compression mechanisms over symbol servers at this time.
+  - Note that HTTP compression is also supported.
 
 After generating symbol files from a build, you can use Windows symstore to store the files in the Microsoft standard symbol store structure. An example invocation of symstore looks like this:
 

docs/error-reporting/platform-integrations/crashpad.md

@@ -1,7 +1,7 @@
 ---
 id: crashpad
 title: Integrating Crashpad
-sidebar_label: Crashpad
+sidebar_label: Integration Guide
 description: Integrate Crashpad in your Backtrace project.
 ---