Feat/basic auth extension

.github/workflows/wdi5-tests_capAuth.yml

@@ -0,0 +1,64 @@
+name: CAP-auth
+on:
+ pull_request:
+ branches:
+ - main
+ - main-v2
+ paths:
+ # relevant
+ - "client-side-js/**"
+ - "examples/**"
+ - "scripts/**"
+ - "src/**"
+ # don't run on changes to these
+ - "!.husky/**"
+ - "!.vscode/**"
+ - "!docs/**"
+ - "!.*"
+ - "!*.md"
+ - "!*.cjs"
+
+env:
+ wdi5_username: "admin" # dummy user for cap app
+
+jobs:
+ authorize:
+ environment: ${{ github.event_name == 'pull_request_target' && github.event.pull_request.head.repo.full_name != github.repository && 'external' || 'internal' }}
+ runs-on: ubuntu-latest
+ steps:
+ - run: true
+
+ tests:
+ needs: authorize
+ runs-on: ubuntu-latest
+
+ strategy:
+ matrix:
+ node-version: [18, 20]
+
+ steps:
+ - name: check out repo
+ uses: actions/checkout@v3
+ with:
+ ref: ${{ github.event.pull_request.head.sha || github.ref }}
+ submodules: recursive
+
+ - name: use node ${{ matrix.node-version }}
+ uses: actions/setup-node@v3
+ with:
+ node-version: ${{ matrix.node-version }}
+ cache: "npm"
+ cache-dependency-path: "**/package-lock.json"
+
+ # install both module + sample app(s) deps + cap submodule
+ - name: install packages (wdi5 + sample app(s))
+ run: |
+ npm pkg delete scripts.prepare
+ npm ci
+
+ # build things
+ - name: build
+ run: npm run build
+
+ - name: cap authentication
+ run: npm run test:capAuth

.gitmodules

@@ -0,0 +1,4 @@
+[submodule "examples/cap-bookshop-wdi5"]
+ path = examples/cap-bookshop-wdi5
+ url = git@github.com:SAP-samples/cap-bookshop-wdi5.git
+ branch = wdi5-tests

docs/authentication.md

@@ -10,17 +10,17 @@
 
 Generally speaking, the authentication behavior mimicks that of a regular user session: first, the `baseUrl` (from the `wdio.conf.(j|t)s`-file) is opened in the configured browser. Then, the redirect to the Authentication provider is awaited and [the credentials](#credentials) are supplied.
 
-BTP-, IAS-, Office365- and custom IdP all supply credentials as a user would, meaning they're literally typed into the respective input fields on each login screen. 
+BTP-, IAS-, Office365- and custom IdP all supply credentials as a user would, meaning they're literally typed into the respective input fields on each login screen.
 Basic Authentication prepends username and password in encoded form to the URL, resulting in an `HTTP` `GET` in the form of `https://username:encoded-pwd@your-deployed-UI5.app`.
 
 !> Multi-Factor Authentication is not supported as it's nearly impossible to manage any media break (e.g. browser ↔ mobile) in authentication flows out of the box
 
-For you as users, authentication is done at design-time, meaning: **by configuration only, not programmatically**. 
+For you as users, authentication is done at design-time, meaning: **by configuration only, not programmatically**.
 This especially means that no changes in the test code are needed for using authentication in `wdi5` tests!
 
 ?> No [skipping of the UI5 injection](configuration#skipinjectui5onstart) is necessary, `wdi5` takes care of the correct order of operation (first authentication, then injecting UI5) itself.
 
-!> Credentials can only be supplied via environment variables, not in any configuration file. 
+!> Credentials can only be supplied via environment variables, not in any configuration file.
 More on the [how and why below](#credentials) :point_down:
 
 ## Configuration
@@ -127,8 +127,8 @@ The `BTP` authenticator will automatically detect whether the login process is a
 
 ?> only available in `wdi5` >= 2
 
-Using the 'Identity Authentication Service (IAS) Authenticator' in `wdi5` is a subset of the [above BTP Authentication](#sap-cloud-idp-default-btp-identity-provider). 
-It takes the same configuration options, plus `disableBiometricAuth` (default: `true`, which you want in almost all cases) and `idpDomain`. The latter is necessary to satisfy cookie conditions in the remote-controlled browser. 
+Using the 'Identity Authentication Service (IAS) Authenticator' in `wdi5` is a subset of the [above BTP Authentication](#sap-cloud-idp-default-btp-identity-provider).
+It takes the same configuration options, plus `disableBiometricAuth` (default: `true`, which you want in almost all cases) and `idpDomain`. The latter is necessary to satisfy cookie conditions in the remote-controlled browser.
 Set `idpDomain` to the _domain-only_ part of your IAS tenant URL, e.g. `weiruhg.accounts.ondemand.com`, _omitting_ the protocol prefix (`https://`).
 
 !> If `disableBiometricAuth` is set to `true`, `idpDomain` must be set as well!
@@ -310,7 +310,8 @@ baseUrl: "https://caution_your-deployed-ui5-with-basic-auth.app",
 capabilities: {
  // browserName: "..."
  "wdi5:authentication": {
- provider: "BasicAuth" //> mandatory
+ provider: "BasicAuth", //> mandatory
+ basicAuthUrls: ["https://your-custom-basic-auth-endpoint"] //> optional: default is the configured `baseUrl`
  }
 }
 ```
@@ -325,7 +326,8 @@ capabilities: {
  capabilities: {
  // browserName: "..."
  "wdi5:authentication": {
- provider: "BasicAuth" //> mandatory
+ provider: "BasicAuth", //> mandatory
+ basicAuthUrls: ["https://your-custom-basic-auth-endpoint"] //> optional: default is the configured `baseUrl`
  }
  }
  },
@@ -334,7 +336,8 @@ capabilities: {
  capabilities: {
  // browserName: "..."
  "wdi5:authentication": {
- provider: "BasicAuth" //> mandatory
+ provider: "BasicAuth", //> mandatory
+ basicAuthUrls: ["https://your-custom-basic-auth-endpoint"] //> optional: default is the configured `baseUrl`
  }
  }
  }
@@ -343,6 +346,7 @@ capabilities: {
 
 <!-- tabs:end -->
 
+
 ## Credentials
 
 Exposing credentials in configuration files that were accidentally checked into version control is one of the most common causes of data leaks. That's why `wdi5` only allows providing credentials through environment variables at runtime.
@@ -351,7 +355,7 @@ Exposing credentials in configuration files that were accidentally checked into
 
 There are multiple ways to achieve that in Node.js, with [using the `dotenv`-module](https://www.npmjs.com/package/dotenv) being one of the most popular: `dotenv` automatically transfers all variables from a `.env`-file into the environment of the app at runtime.
 
-In single browser scenarios, `wdi5_username` and `wdi5_password` need to be provided. 
+In single browser scenarios, `wdi5_username` and `wdi5_password` need to be provided.
 In multiremote scenarios, credential keys in the environment adhere to `wdi5_$browserInstanceName_username` and `wdi5_$browserInstanceName_password`.
 
 <!-- tabs:start -->
@@ -381,5 +385,5 @@ wdi5_nix_password='dmac'
 
 ## Miscellaneous
 
-Why the `wdi5:...` prefix? 
+Why the `wdi5:...` prefix?
 Because the W3C standard for providing options in the WebDriver protocol asks for any vendor-specfic setting to have a unique prefix.

examples/ui5-ts-app/webapp/index.html

@@ -1,4 +1,4 @@
-<!DOCTYPE html>
+<!doctype html>
 <html>
  <head>
  <meta http-equiv="Cache-control" content="no-cache, no-store, must-revalidate" />