fix build issues: add attributes+ on codeblocks to prevent XML parsing error, fix anchor ID problems due to duplicate titles (#60)

WORKAROUND: replace xref target with link anchor that actually show up in the XML after conversion

server_admin/topics/authentication/clients/oidc/con-basic-settings.adoc

@@ -15,7 +15,8 @@ the name, set up a replacement string value. For example, a string value such as
 
 *Consent Required*:: When turned on, users see a consent page that they can use to grant access to that application.  It will also display metadata so the user knows the exact information that the client can access.
 
-[[_access-type]]*Access Type*:: The type of OIDC client.
+[[_access-type]]
+*Access Type*:: The type of OIDC client.
 
 _Confidential_::
   For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications.
@@ -34,7 +35,7 @@ _Bearer-only_::
 
 *OAuth 2.0 Device Authorization Grant Enabled*
 
-If this is on, clients are allowed to use the OIDC <<_oidc-auth-flows,Device Authorization Grant>>.
+If this is on, clients are allowed to use the OIDC xref:con-oidc-auth-flows_server_administration_guide[Device Authorization Grant].
 
 *Root URL*:: This value adds a prefix to any configured URLS that {project_name} uses.
 

server_admin/topics/identity-broker/social/openshift.adoc

@@ -11,7 +11,7 @@ image:images/openshift-add-identity-provider.png[Add Identity Provider]
 . Copy the value of *Redirect URI* to your clipboard.
 . Register your client using the `oc` command-line tool.
 +
-[source, subs="attributes"]
+[source,subs="attributes+"]
 ----
 $ oc create -f <(echo '
 kind: OAuthClient
@@ -24,6 +24,7 @@ redirectURIs:
 grantMethod: prompt <4>
 ')
 ----
+
 <1> The `name` of your OAuth client. Passed as `client_id` request parameter when making requests to `_<openshift_master>_/oauth/authorize` and `_<openshift_master>_/oauth/token`.
 <2> The `secret` {project_name} uses for the `client_secret` request parameter.
 <3> The `redirect_uri` parameter specified in requests to `_<openshift_master>_/oauth/authorize` and `_<openshift_master>_/oauth/token` must be equal to (or prefixed by) one of the URIs in `redirectURIs`. You can obtain this from the *Redirect URI* field in the Identity Provider screen
@@ -42,7 +43,7 @@ grantMethod: prompt <4>
 .Procedure
 . Run the following command on the command line and note the OpenShift 4 API URL output.
 +
-[source, subs="attributes"]
+[source,subs="attributes+"]
 ----
 curl -s -k -H "Authorization: Bearer $(oc whoami -t)" \https://<openshift-user-facing-api-url>/apis/config.openshift.io/v1/infrastructures/cluster | jq ".status.apiServerURL"
 ----
@@ -56,7 +57,7 @@ image:images/openshift-4-add-identity-provider.png[Add Identity Provider]
 . Copy the value of *Redirect URI* to your clipboard.
 . Register your client using the `oc` command-line tool.
 +
-[source, subs="attributes"]
+[source, subs="attributes+"]
 ----
 $ oc create -f <(echo '
 kind: OAuthClient

server_admin/topics/identity-broker/tokens.adoc

@@ -5,7 +5,7 @@ With {project_name}, you can store tokens and responses from the authentication
 
 Application code can retrieve these tokens and responses to import extra user information or to request the external IDP securely. For example, an application can use the Google token to use other Google services and REST APIs. To retrieve a token for a particular identity provider, send a request as follows:
 
-[source, subs="attributes"]
+[source,subs="attributes+"]
 ----
 GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1
 Host: localhost:8080

server_admin/topics/realms/master.adoc

@@ -7,7 +7,7 @@ In the Admin Console, two types of realms exist:
 * `Other realms` - These realms are created by the administrator in the master realm. In these realms, administrators manage the users in your organization and the applications they need. The applications are owned by the users.
 
 .Realms and applications
-image:../../../getting_started/images/master_realm.png[Realms and applications]
+image:getting_started/images/master_realm.png[Realms and applications]
 
 Realms are isolated from one another and can only manage and authenticate the users that they control. Following this security model helps prevent accidental changes and follows the tradition
 of permitting user accounts access to only those privileges and powers necessary