KEYCLOAK-16522 fix test issues (external links and anchor) (#44)

securing_apps/topics/oidc/java/java-adapter-config.adoc

@@ -284,4 +284,4 @@ verify-token-audience::
   If set to `true`, then during authentication with the bearer token, the adapter will verify whether the token contains this
   client name (resource) as an audience. The option is especially useful for services, which primarily serve requests authenticated
   by the bearer token. This is set to `false` by default, however for improved security, it is recommended to enable this.
-  See link:{adminguide_link}#_audience[Audience Support] for more details about audience support.
+  See link:{adminguide_link}#audience-support[Audience Support] for more details about audience support.

securing_apps/topics/oidc/java/jetty9-adapter.adoc

@@ -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.
 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/jetty-9/index.html#startup-base-and-home[base directory].
+You must unzip the Jetty 9.x  distro into Jetty 9.x's link:https://www.eclipse.org/jetty/documentation/current/#quickstart-common-config[base directory].
 Including adapter's jars within your WEB-INF/lib directory will not work!
 In the example below, the Jetty base is named `your-base`:
 

server_admin/topics/roles-groups/con-default-roles.adoc

@@ -0,0 +1,13 @@
+[id="con-default-roles_{context}"]
+
+[[_default_roles]]
+==== Default Roles
+[role="_abstract"]
+Default roles allow you to automatically assign user role mappings when any user is newly created or imported through
+<<_identity_broker, Identity Brokering>>.
+To specify default roles go to the *Roles* left menu item, and click the *Default Roles* tab.
+
+.Default Roles
+image:{project_images}/default-roles.png[]
+
+This screenshot shows that some _default roles_ already exist.

server_installation/topics/clustering/sticky-sessions.adoc

@@ -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).
 * {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.
-See link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#distribution-configuring[Infinispan documentation] for more details around this.
+See link:https://infinispan.org/docs/10.1.x/titles/configuring/configuring.html#clustered_caches[Infinispan documentation] for more details around this.
 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` .
 * Response is returned to the user with the {project_name} login screen and the AUTH_SESSION_ID cookie in the browser

server_installation/topics/operating-mode/crossdc.adoc

@@ -137,10 +137,9 @@ For more detail about how caches can be configured see <<tuningcache>>.
 [[communication]]
 ==== 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 {jdgserver_name} servers for communication across data centers. This is done using the link:https://infinispan.org/docs/11.0.x/titles/hotrod_java/hotrod_java.html[Infinispan Hot Rod 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/10.1.x/titles/server/server.html#hot_rod[Infinispan HotRod protocol].
 
-The Infinispan caches on the {project_name} side use link:https://infinispan.org/docs/stable/titles/configuring/configuring.html#remote_cache_store[`remoteStore`] configuration to offload data to a remote {jdgserver_name} cluster.
-{jdgserver_name} clusters in separate data centers then replicate that data to ensure it is backed up.
+The Infinispan caches on the {project_name} side must be configured with the link:https://infinispan.org/docs/10.1.x/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` .
 
 The receiving {jdgserver_name} server notifies the {project_name} servers in its cluster through Client Listeners, which are a feature of the Hot Rod 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`.
 

tests/src/test/resources/ignored-links

@@ -8,6 +8,7 @@ http://localhost:8181*
 http://127.0.0.1:3000*
 https://myhost.com/myapp/k_jwks
 https://myhost.com/myapp
+http://host.com/*
 http://host:port*
 https://host:port*
 http://broker-keycloak:8180*

upgrading/topics/keycloak/changes.adoc

@@ -441,7 +441,7 @@ or `resourceAccess` properties, you may need to increase the priority of your ma
 
 Audiences of all the clients, for which authenticated user has at least one client role in the token, are automatically added
 to the `aud` claim in the access token now. On the other hand, an access token may not automatically contain the audience of the
-frontend client, for which it was issued. Read the link:{adminguide_link}#_audience[{adminguide_name}] for more details.
+frontend client, for which it was issued. Read the link:{adminguide_link}#audience-support[{adminguide_name}] for more details.
 
 ==== JavaScript Adapter Promise