[KEYCLOAK-16788] Fix broken links

This commit is contained in:
Stefan Guilhen 2021-01-12 15:03:33 -03:00 committed by Hynek Mlnařík
parent f51560fb90
commit 9a21c9cb05
6 changed files with 11 additions and 11 deletions

View file

@ -20,7 +20,7 @@ jobs:
with: with:
java-version: 1.8 java-version: 1.8
- name: Build with Maven - name: Build with Maven
run: mvn package run: mvn package -B
build-product: build-product:
name: Build and test Product documentation name: Build and test Product documentation
runs-on: ubuntu-latest runs-on: ubuntu-latest
@ -31,4 +31,4 @@ jobs:
with: with:
java-version: 1.8 java-version: 1.8
- name: Build with Maven - name: Build with Maven
run: mvn package -Dproduct run: mvn package -B -Dproduct

View file

@ -158,11 +158,11 @@ Two features have a change in status:
= Fixed Issues = Fixed Issues
More than 1100 issues were fixed during this release. For details on the fixed issues, see link:https://issues.redhat.com/issues/?filter=12346377[https://issues.redhat.com/issues/?filter=12346377]. More than 1100 issues were fixed during this release. For details on the fixed issues, see link:https://issues.redhat.com/browse/KEYCLOAK-13785?filter=12346377[https://issues.redhat.com/issues/?filter=12346377].
= Known issues = Known issues
This release includes the following link:https://issues.redhat.com/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20issuetype%20%3D%20Bug%20AND%20fixVersion%20%3D%209.0.4%20AND%20component%20not%20in%20(Infra%2C%20Testsuite%2C%20%22Testsuite%20-%20Performance%22)[known issues] and in particular these higher level issues. This release includes the following known issues:
* link:https://issues.redhat.com/browse/KEYCLOAK-13589[KEYCLOAK-13589] - Can't add user in admin console when 'Email as username' is enabled * link:https://issues.redhat.com/browse/KEYCLOAK-13589[KEYCLOAK-13589] - Can't add user in admin console when 'Email as username' is enabled

View file

@ -12,7 +12,7 @@ Let's go over these steps.
Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on the Keycloak download site. Adapters are no longer included with the appliance or war distribution. Each adapter is a separate download on the Keycloak download site.
They are also available as a maven artifact. They are also available as a maven artifact.
You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/current/startup-base-and-home.html[base directory]. You must unzip the Jetty 9.x distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/jetty-9/index.html#startup-base-and-home[base directory].
Including adapter's jars within your WEB-INF/lib directory will not work! Including adapter's jars within your WEB-INF/lib directory will not work!
In the example below, the Jetty base is named `your-base`: In the example below, the Jetty base is named `your-base`:

View file

@ -2,7 +2,7 @@
=== W3C Web Authentication (WebAuthn) === W3C Web Authentication (WebAuthn)
{project_name} provides the limited support for https://www.w3.org/TR/webauthn/[W3C Web Authentication (WebAuthn)]. {project_name} works as a WebAuthn's https://www.w3.org/TR/webauthn/#rp-operations[Relying Party (RP)]. {project_name} provides the limited support for https://www.w3.org/TR/webauthn/[W3C Web Authentication (WebAuthn)]. {project_name} works as a WebAuthn's https://www.w3.org/TR/webauthn/#sctn-rp-operations[Relying Party (RP)].
ifeval::[{project_product}==true] ifeval::[{project_product}==true]
:tech_feature_name: WebAuthn :tech_feature_name: WebAuthn
@ -122,14 +122,14 @@ The configurable items and their description follow.
|Attestation Conveyance Preference |Attestation Conveyance Preference
|It tells the WebAuthn API implementation on the browser (https://www.w3.org/TR/webauthn/#webauthn-client[WebAuthn Client]) the preference of how to generate an Attestation Statement. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "none". |It tells the WebAuthn API implementation on the browser (https://www.w3.org/TR/webauthn/#webauthn-client[WebAuthn Client]) the preference of how to generate an Attestation Statement. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "none".
For more details, see https://www.w3.org/TR/webauthn/#attestation-convey[WebAuthn Specification]. For more details, see https://www.w3.org/TR/webauthn/#attestation-conveyance[WebAuthn Specification].
|Authenticator Attachment |Authenticator Attachment
|It tells the WebAuthn Client an acceptable attachment pattern of a WebAuthn authenticator. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, the WebAuthn Client does not consider the attachment pattern. |It tells the WebAuthn Client an acceptable attachment pattern of a WebAuthn authenticator. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, the WebAuthn Client does not consider the attachment pattern.
For more details, see https://www.w3.org/TR/webauthn/#enumdef-authenticatorattachment[WebAuthn Specification]. For more details, see https://www.w3.org/TR/webauthn/#enumdef-authenticatorattachment[WebAuthn Specification].
|Require Resident Key |Require Resident Key
|It tells the WebAuthn authenticator to generate the Public Key Credential as https://www.w3.org/TR/webauthn/#client-side-resident-public-key-credential-source[Client-side-resident Public Key Credential Source]. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "No". |It tells the WebAuthn authenticator to generate the Public Key Credential as https://www.w3.org/TR/webauthn/#client-side-discoverable-public-key-credential-source[Client-side-resident Public Key Credential Source]. This is an optional configuration item that is applied to the operation of registering a WebAuthn authenticator. If no option is selected, its behavior is the same as selecting "No".
For more details, see https://www.w3.org/TR/webauthn/#dom-authenticatorselectioncriteria-requireresidentkey[WebAuthn Specification]. For more details, see https://www.w3.org/TR/webauthn/#dom-authenticatorselectioncriteria-requireresidentkey[WebAuthn Specification].
|User Verification Requirement |User Verification Requirement

View file

@ -19,7 +19,7 @@ The workflow in the cluster environment with the public frontend load balancer a
but can be chosen according to some other criterias (client IP address etc). It all depends on the implementation and configuration of underlying load balancer (reverse proxy). but can be chosen according to some other criterias (client IP address etc). It all depends on the implementation and configuration of underlying load balancer (reverse proxy).
* {project_name} creates authentication session with random ID (eg. 123) and saves it to the Infinispan cache. * {project_name} creates authentication session with random ID (eg. 123) and saves it to the Infinispan cache.
* Infinispan distributed cache assigns the primary owner of the session based on the hash of session ID. * Infinispan distributed cache assigns the primary owner of the session based on the hash of session ID.
See link:https://infinispan.org/docs/8.2.x/user_guide/user_guide.html#distribution_mode[Infinispan documentation] for more details around this. See link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#distribution-configuring[Infinispan documentation] for more details around this.
Let's assume that Infinispan assigned `node2` to be the owner of this session. Let's assume that Infinispan assigned `node2` to be the owner of this session.
* {project_name} creates the cookie `AUTH_SESSION_ID` with the format like `<session-id>.<owner-node-id>` . In our example case, it will be `123.node2` . * {project_name} creates the cookie `AUTH_SESSION_ID` with the format like `<session-id>.<owner-node-id>` . In our example case, it will be `123.node2` .
* Response is returned to the user with the {project_name} login screen and the AUTH_SESSION_ID cookie in the browser * Response is returned to the user with the {project_name} login screen and the AUTH_SESSION_ID cookie in the browser

View file

@ -132,9 +132,9 @@ For more detail about how caches can be configured see <<tuningcache>>.
[[communication]] [[communication]]
==== Communication details ==== Communication details
{project_name} uses multiple, separate clusters of Infinispan caches. Every {project_name} node is in the cluster with the other {project_name} nodes in same data center, but not with the {project_name} nodes in different data centers. A {project_name} node does not communicate directly with the {project_name} nodes from different data centers. {project_name} nodes use external JDG (actually {jdgserver_name} servers) for communication across data centers. This is done using the link:https://infinispan.org/docs/8.2.x/user_guide/user_guide.html#using_hot_rod_server[Infinispan HotRod protocol]. {project_name} uses multiple, separate clusters of Infinispan caches. Every {project_name} node is in the cluster with the other {project_name} nodes in same data center, but not with the {project_name} nodes in different data centers. A {project_name} node does not communicate directly with the {project_name} nodes from different data centers. {project_name} nodes use external JDG (actually {jdgserver_name} servers) for communication across data centers. This is done using the link:https://infinispan.org/docs/stable/titles/hotrod_java/hotrod_java.html[Infinispan HotRod protocol].
The Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/8.2.x/user_guide/user_guide.html#remote_store[remoteStore] to ensure that data are saved to the remote cache. There is separate Infinispan cluster between JDG servers, so the data saved on JDG1 on `site1` are replicated to JDG2 on `site2` . The Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#remote_cache_store[remoteStore] to ensure that data are saved to the remote cache. There is separate Infinispan cluster between JDG servers, so the data saved on JDG1 on `site1` are replicated to JDG2 on `site2` .
Finally, the receiving JDG server notifies the {project_name} servers in its cluster through the Client Listeners, which are a feature of the HotRod protocol. {project_name} nodes on `site2` then update their Infinispan caches and the particular user session is also visible on {project_name} nodes on `site2`. Finally, the receiving JDG server notifies the {project_name} servers in its cluster through the Client Listeners, which are a feature of the HotRod protocol. {project_name} nodes on `site2` then update their Infinispan caches and the particular user session is also visible on {project_name} nodes on `site2`.