[DOCS] Update snippets in security APIs (#46191)

x-pack/docs/en/rest-api/security/authenticate.asciidoc

@@ -31,15 +31,14 @@ If the user cannot be authenticated, this API returns a 401 status code.
 To authenticate a user, submit a GET request to the
 `/_security/_authenticate` endpoint:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/_authenticate
 --------------------------------------------------
-// CONSOLE
 
 The following example output provides information about the "rdeniro" user:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "username": "rdeniro",

x-pack/docs/en/rest-api/security/change-password.asciidoc

@@ -51,20 +51,18 @@ For more information about the native realm, see
 
 The following example updates the password for the `jacknich` user:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/user/jacknich/_password
 {
   "password" : "s3cr3t"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:jacknich_user]
 
 A successful call returns an empty JSON structure.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {}
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/clear-cache.asciidoc

@@ -44,25 +44,22 @@ To evict roles from the role cache, see the
 
 For example, to evict all users cached by the `file` realm:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/realm/default_file/_clear_cache
 --------------------------------------------------
-// CONSOLE
 
 To evict selected users, specify the `usernames` parameter:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/realm/default_file/_clear_cache?usernames=rdeniro,alpacino
 --------------------------------------------------
-// CONSOLE
 
 To clear the caches for multiple realms, specify the realms as a comma-delimited
 list:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/realm/default_file,ldap1/_clear_cache
 ------------------------------------------------------------
-// CONSOLE

x-pack/docs/en/rest-api/security/clear-roles-cache.asciidoc

@@ -36,8 +36,7 @@ For more information about the native realm, see
 The clear roles cache API evicts roles from the native role cache. For example, 
 to clear the cache for `my_admin_role`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/role/my_admin_role/_clear_cache
 --------------------------------------------------
-// CONSOLE

x-pack/docs/en/rest-api/security/create-api-keys.asciidoc

@@ -65,7 +65,7 @@ expire.
 
 The following example creates an API key:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/api_key
 {
@@ -93,7 +93,6 @@ POST /_security/api_key
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 <1> optional expiration for the API key being generated. If expiration is not
  provided then the API keys do not expire.
 <2> optional role descriptors for this API key, if not provided then permissions
@@ -102,7 +101,7 @@ POST /_security/api_key
 A successful call returns a JSON structure that provides
 API key information.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "id":"VuaCfGcBCdbkQm-e5aOx", <1>

x-pack/docs/en/rest-api/security/create-role-mappings.asciidoc

@@ -105,7 +105,7 @@ The Examples section below demonstrates the use of templated role names.
 
 The following example assigns the "user" role to all users:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping1
 {
@@ -119,7 +119,6 @@ POST /_security/role_mapping/mapping1
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 <1> Mappings that have `enabled` set to `false` are ignored when role mapping
     is performed.
 <2> Metadata is optional.
@@ -127,7 +126,7 @@ POST /_security/role_mapping/mapping1
 A successful call returns a JSON structure that shows whether the mapping has
 been created or updated.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "role_mapping" : {
@@ -135,12 +134,11 @@ been created or updated.
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
 <1> When an existing mapping is updated, `created` is set to false.
 
 The following example assigns the "user" and "admin" roles to specific users:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/role_mapping/mapping2
 {
@@ -151,10 +149,9 @@ POST /_security/role_mapping/mapping2
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example matches users who authenticated against a specific realm:
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping3
 {
@@ -165,12 +162,11 @@ POST /_security/role_mapping/mapping3
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 
 The following example matches any user where either the username is `esadmin`
 or the user is in the `cn=admin,dc=example,dc=com` group:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping4
 {
@@ -192,7 +188,6 @@ POST /_security/role_mapping/mapping4
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 
 The example above is useful when the group names in your identity management
 system (such as Active Directory, or a SAML Identity Provider) do not have a
@@ -213,7 +208,7 @@ roles is inefficient and can have a negative effect on system performance.
 If you only need to map a subset of the groups, then you should do this
 using explicit mappings.
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping5
 {
@@ -229,7 +224,6 @@ POST /_security/role_mapping/mapping5
   "enabled": true
 }
 ------------------------------------------------------------
-// CONSOLE
 <1> The `tojson` mustache function is used to convert the list of
     group names into a valid JSON array.
 <2> Because the template produces a JSON array, the format must be
@@ -237,7 +231,7 @@ POST /_security/role_mapping/mapping5
 
 The following example matches users within a specific LDAP sub-tree:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping6
 {
@@ -248,12 +242,11 @@ POST /_security/role_mapping/mapping6
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 
 The following example matches users within a particular LDAP sub-tree in a
 specific realm:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping7
 {
@@ -267,7 +260,6 @@ POST /_security/role_mapping/mapping7
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 
 The rules can be more complex and include wildcard matching. For example, the
 following mapping matches any user where *all* of these conditions are met:
@@ -278,7 +270,7 @@ following mapping matches any user where *all* of these conditions are met:
 - the user does not have a `terminated_date`
 
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping8
 {
@@ -316,7 +308,6 @@ POST /_security/role_mapping/mapping8
   }
 }
 ------------------------------------------------------------
-// CONSOLE
 
 A templated role can be used to automatically map every user to their own
 custom role. The role itself can be defined through the
@@ -329,7 +320,7 @@ role that is their username prefixed with `_user_`.
 As an example, the user `nwong` would be assigned the `saml_user` and
 `_user_nwong` roles.
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/role_mapping/mapping9
 {
@@ -341,7 +332,6 @@ POST /_security/role_mapping/mapping9
   "enabled": true
 }
 ------------------------------------------------------------
-// CONSOLE
 <1> Because it is not possible to specify both `roles` and `role_templates` in
     the same role mapping, we can apply a "fixed name" role by using a template
     that has no substitutions.

x-pack/docs/en/rest-api/security/create-roles.asciidoc

@@ -82,7 +82,7 @@ For more information, see {stack-ov}/defining-roles.html[Defining roles].
 
 The following example adds a role called `my_admin_role`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/role/my_admin_role
 {
@@ -110,12 +110,11 @@ POST /_security/role/my_admin_role
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 A successful call returns a JSON structure that shows whether the role has been
 created or updated.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "role": {
@@ -123,5 +122,4 @@ created or updated.
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
 <1> When an existing role is updated, `created` is set to false.

x-pack/docs/en/rest-api/security/create-users.asciidoc

@@ -104,7 +104,7 @@ access  permissions. To create a user without any roles, specify an empty list:
 
 The following example creates a user `jacknich`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/user/jacknich
 {
@@ -117,18 +117,16 @@ POST /_security/user/jacknich
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 A successful call returns a JSON structure that shows whether the user has been
 created or updated.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "created": true <1>
 }
 --------------------------------------------------
-// TESTRESPONSE
 <1> When an existing user is updated, `created` is set to false.
 
 After you add a user, requests from that user can be authenticated. For example:

x-pack/docs/en/rest-api/security/delegate-pki-authentication.asciidoc

@@ -73,19 +73,18 @@ client's certificate.
 
 The following is an example request:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/delegate_pki
 {
   "x509_certificate_chain": ["MIIDbTCCAlWgAwIBAgIJAIxTS7Qdho9jMA0GCSqGSIb3DQEBCwUAMFMxKzApBgNVBAMTIkVsYXN0aWNzZWFyY2ggVGVzdCBJbnRlcm1lZGlhdGUgQ0ExFjAUBgNVBAsTDUVsYXN0aWNzZWFyY2gxDDAKBgNVBAoTA29yZzAeFw0xOTA3MTkxMzMzNDFaFw0yMzA3MTgxMzMzNDFaMEoxIjAgBgNVBAMTGUVsYXN0aWNzZWFyY2ggVGVzdCBDbGllbnQxFjAUBgNVBAsTDUVsYXN0aWNzZWFyY2gxDDAKBgNVBAoTA29yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANHgMX2aX8t0nj4sGLNuKISmmXIYCj9RwRqS7L03l9Nng7kOKnhHu/nXDt7zMRJyHj+q6FAt5khlavYSVCQyrDybRuA5z31gOdqXerrjs2OXS5HSHNvoDAnHFsaYX/5geMewVTtc/vqpd7Ph/QtaKfmG2FK0JNQo0k24tcgCIcyMtBh6BA70yGBM0OT8GdOgd/d/mA7mRhaxIUMNYQzRYRsp4hMnnWoOTkR5Q8KSO3MKw9dPSpPe8EnwtJE10S3s5aXmgytru/xQqrFycPBNj4KbKVmqMP0G60CzXik5pr2LNvOFz3Qb6sYJtqeZF+JKgGWdaTC89m63+TEnUHqk0lcCAwEAAaNNMEswCQYDVR0TBAIwADAdBgNVHQ4EFgQU/+aAD6Q4mFq1vpHorC25/OY5zjcwHwYDVR0jBBgwFoAU8siFCiMiYZZm/95qFC75AG/LRE0wDQYJKoZIhvcNAQELBQADggEBAIRpCgDLpvXcgDHUk10uhxev21mlIbU+VP46ANnCuj0UELhTrdTuWvO1PAI4z+WbDUxryQfOOXO9R6D0dE5yR56L/J7d+KayW34zU7yRDZM7+rXpocdQ1Ex8mjP9HJ/Bf56YZTBQJpXeDrKow4FvtkI3bcIMkqmbG16LHQXeG3RS4ds4S4wCnE2nA6vIn9y+4R999q6y1VSBORrYULcDWxS54plHLEdiMr1vVallg82AGobS9GMcTL2U4Nx5IYZG7sbTk3LrDxVpVg/S2wLofEdOEwqCeHug/iOihNLJBabEW6z4TDLJAVW5KCY1DfhkYlBfHn7vxKkfKoCUK/yLWWI="] <1>
 }
 ------------------------------------------------------------
-// CONSOLE
 <1>  A one element certificate chain.
 
 Which returns the following response:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",

x-pack/docs/en/rest-api/security/delete-app-privileges.asciidoc

@@ -38,17 +38,16 @@ To use this API, you must have either:
 The following example deletes the `read` application privilege from the 
 `myapp` application:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/privilege/myapp/read
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:app0102_privileges] 
 
 If the role is successfully deleted, the request returns `{"found": true}`.
 Otherwise, `found` is set to false.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "myapp": {
@@ -58,5 +57,3 @@ Otherwise, `found` is set to false.
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
-

x-pack/docs/en/rest-api/security/delete-role-mappings.asciidoc

@@ -37,20 +37,18 @@ see {stack-ov}/mapping-roles.html[Mapping users and groups to roles].
 
 The following example delete a role mapping:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/role_mapping/mapping1
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:role_mapping]
 
 If the mapping is successfully deleted, the request returns `{"found": true}`.
 Otherwise, `found` is set to false.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "found" : true
 }
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/delete-roles.asciidoc

@@ -38,21 +38,19 @@ file-based role management. For more information about the native realm, see
 
 The following example deletes a `my_admin_role` role:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/role/my_admin_role
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:admin_role]
 
 If the role is successfully deleted, the request returns `{"found": true}`.
 Otherwise, `found` is set to false.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "found" : true
 }
 --------------------------------------------------
-// TESTRESPONSE
 

x-pack/docs/en/rest-api/security/delete-users.asciidoc

@@ -35,20 +35,18 @@ For more information about the native realm, see
 
 The following example deletes the user `jacknich`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/user/jacknich
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:jacknich_user]
 
 If the user is successfully deleted, the request returns `{"found": true}`.
 Otherwise, `found` is set to false.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "found" : true
 }
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/disable-users.asciidoc

@@ -41,9 +41,8 @@ For more information about the native realm, see
 
 The following example disables the user `jacknich`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /_security/user/jacknich/_disable
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:jacknich_user]

x-pack/docs/en/rest-api/security/enable-users.asciidoc

@@ -40,9 +40,8 @@ For more information about the native realm, see
 
 The following example enables the user `jacknich`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /_security/user/jacknich/_enable
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:jacknich_user]

x-pack/docs/en/rest-api/security/get-api-keys.asciidoc

@@ -59,7 +59,7 @@ NOTE: At least one of "id", "name", "username" and "realm_name" must be specifie
 
 If you create an API key as follows:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/api_key
 {
@@ -67,13 +67,11 @@ POST /_security/api_key
   "role_descriptors": {}
 }
 ------------------------------------------------------------
-// CONSOLE
-// TEST
 
 A successful call returns a JSON structure that provides
 API key information. For example:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "id":"VuaCfGcBCdbkQm-e5aOx",
@@ -86,80 +84,72 @@ API key information. For example:
 
 You can use the following example to retrieve the API key by ID:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?id=VuaCfGcBCdbkQm-e5aOx
 --------------------------------------------------
-// CONSOLE
 // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/]
 // TEST[continued]
 
 You can use the following example to retrieve the API key by name:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?name=my-api-key
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 The following example retrieves all API keys for the `native1` realm:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?realm_name=native1
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 The following example retrieves all API keys for the user `myuser` in all realms:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?username=myuser
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 The following example retrieves all API keys owned by the currently authenticated user:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?owner=true
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 Following creates an API key
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/api_key
 {
   "name": "my-api-key-1"
 }
 ------------------------------------------------------------
-// CONSOLE
 
 The following example retrieves the API key identified by the specified `id` if
 it is owned by the currently authenticated user:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?id=VuaCfGcBCdbkQm-e5aOx&owner=true
 --------------------------------------------------
-// CONSOLE
 // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/]
 // TEST[continued]
 
 Finally, the following example retrieves all API keys for the user `myuser` in
  the `native1` realm immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/api_key?username=myuser&realm_name=native1
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 
 A successful call returns a JSON structure that contains the information of one or more API keys that were retrieved.

x-pack/docs/en/rest-api/security/get-app-privileges.asciidoc

@@ -55,17 +55,16 @@ To check a user's application privileges, use the
 The following example retrieves information about the `read` privilege for the 
 `app01` application:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/privilege/myapp/read
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:app0102_privileges]
 
 A successful call returns an object keyed by application name and privilege
 name. If the privilege is not defined, the request responds with a 404 status.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "myapp": {
@@ -83,20 +82,17 @@ name. If the privilege is not defined, the request responds with a 404 status.
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
 
 To retrieve all privileges for an application, omit the privilege name:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/privilege/myapp/
 --------------------------------------------------
-// CONSOLE
 
 To retrieve every privilege, omit both the application and privilege names:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/privilege/
 --------------------------------------------------
-// CONSOLE

x-pack/docs/en/rest-api/security/get-builtin-privileges.asciidoc

@@ -51,16 +51,14 @@ The response is an object with two fields:
 
 The following example retrieves the names of all builtin privileges:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/privilege/_builtin
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 A successful call returns an object with "cluster" and "index" fields.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "cluster" : [
@@ -115,4 +113,3 @@ A successful call returns an object with "cluster" and "index" fields.
   ]
 }
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/get-role-mappings.asciidoc

@@ -55,15 +55,14 @@ response will have status code `404`.
 
 The following example retrieves information about the `mapping1` role mapping:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/role_mapping/mapping1
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:role_mapping]
 
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "mapping1": {
@@ -80,4 +79,3 @@ GET /_security/role_mapping/mapping1
   }
 }
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/get-roles.asciidoc

@@ -51,14 +51,13 @@ If the role is not defined in the native realm, the request returns 404.
 The following example retrieves information about the `my_admin_role` role in 
 the native realm:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/role/my_admin_role
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:admin_role]
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "my_admin_role": {
@@ -83,14 +82,12 @@ GET /_security/role/my_admin_role
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
 
 To retrieve all roles, omit the role name:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/role
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]
 

x-pack/docs/en/rest-api/security/get-tokens.asciidoc

@@ -98,19 +98,18 @@ other supported grant type.
 The following example obtains a token using the `client_credentials` grant type,
 which simply creates a token as the authenticated user:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oauth2/token
 {
   "grant_type" : "client_credentials"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output contains the access token, the amount of time (in
 seconds) that the token expires in, and the type:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",
@@ -134,7 +133,7 @@ The following example obtains a token for the `test_admin` user using the
 `password` grant type. This request needs to be made by an authenticated user with sufficient privileges that may
 or may not be the same as the one whose username is passed in the `username` parameter:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oauth2/token
 {
@@ -143,12 +142,11 @@ POST /_security/oauth2/token
   "password" : "x-pack-test-password"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output contains the access token, the amount of time (in
 seconds) that the token expires in, the type, and the refresh token:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",
@@ -165,7 +163,7 @@ To extend the life of an existing token obtained using the `password` grant type
 you can call the API again with the refresh token within 24 hours of the token's
 creation. For example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oauth2/token
 {
@@ -173,14 +171,13 @@ POST /_security/oauth2/token
     "refresh_token": "vLBPvmAB6KvwvJZr27cS"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/]
 // TEST[continued]
 
 The API will return a new token and refresh token. Each refresh token may only 
 be used one time.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",

x-pack/docs/en/rest-api/security/get-users.asciidoc

@@ -52,14 +52,13 @@ If the user is not defined in the `native` realm, the request 404s.
 To retrieve a native user, submit a GET request to the `/_security/user/<username>`
 endpoint:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/user/jacknich
 --------------------------------------------------
-// CONSOLE
 // TEST[setup:jacknich_user]
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {  
   "jacknich": {
@@ -74,14 +73,11 @@ GET /_security/user/jacknich
   }
 }
 --------------------------------------------------
-// CONSOLE
-// TESTRESPONSE
 
 Omit the username to retrieve all users:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/user
 --------------------------------------------------
-// CONSOLE
 // TEST[continued]

x-pack/docs/en/rest-api/security/has-privileges.asciidoc

@@ -64,7 +64,7 @@ should be checked
 The following example checks whether the current user has a specific set of
 cluster, index, and application privileges:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_security/user/_has_privileges
 {
@@ -88,11 +88,10 @@ GET /_security/user/_has_privileges
   ]
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output indicates which privileges the "rdeniro" user has:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "username": "rdeniro",

x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc

@@ -68,20 +68,18 @@ keys.
 
 If you create an API key as follows:
 
-[source, js]
+[source,console]
 ------------------------------------------------------------
 POST /_security/api_key
 {
   "name": "my-api-key"
 }
 ------------------------------------------------------------
-// CONSOLE
-// TEST
 
 A successful call returns a JSON structure that provides
 API key information. For example:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "id":"VuaCfGcBCdbkQm-e5aOx",
@@ -95,60 +93,53 @@ API key information. For example:
 The following example invalidates the API key identified by specified `id`
 immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
   "id" : "VuaCfGcBCdbkQm-e5aOx"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[s/VuaCfGcBCdbkQm-e5aOx/$body.id/]
 // TEST[continued]
 
 The following example invalidates the API key identified by specified `name`
 immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
   "name" : "my-api-key"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The following example invalidates all API keys for the `native1` realm
 immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
   "realm_name" : "native1"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The following example invalidates all API keys for the user `myuser` in all
 realms immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
   "username" : "myuser"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The following example invalidates the API key identified by the specified `id` if
  it is owned by the currently authenticated user immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
@@ -156,25 +147,22 @@ DELETE /_security/api_key
   "owner" : "true"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example invalidates all API keys owned by the currently authenticated
  user immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
   "owner" : "true"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 Finally, the following example invalidates all API keys for the user `myuser` in
  the `native1` realm immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/api_key
 {
@@ -182,8 +170,6 @@ DELETE /_security/api_key
   "realm_name" : "native1"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 [source,js]
 --------------------------------------------------

x-pack/docs/en/rest-api/security/invalidate-tokens.asciidoc

@@ -68,19 +68,17 @@ and potentially a list of errors encountered while invalidating specific tokens.
 For example, if you create a token using the `client_credentials` grant type as
 follows:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oauth2/token
 {
   "grant_type" : "client_credentials"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The get token API returns the following information about the access token:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",
@@ -88,27 +86,25 @@ The get token API returns the following information about the access token:
   "expires_in" : 1200
 }
 --------------------------------------------------
-// CONSOLE
 // TESTRESPONSE[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/]
 
 This access token can now be immediately invalidated, as shown in the following
 example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/oauth2/token
 {
   "token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ=="
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/]
 // TEST[continued]
 
 If you used the `password` grant type to obtain a token for a user, the response
 might also contain a refresh token. For example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oauth2/token
 {
@@ -117,12 +113,10 @@ POST /_security/oauth2/token
   "password" : "x-pack-test-password"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The get token API returns the following information:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "access_token" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==",
@@ -131,54 +125,48 @@ The get token API returns the following information:
   "refresh_token": "vLBPvmAB6KvwvJZr27cS"
 }
 --------------------------------------------------
-// CONSOLE
 // TESTRESPONSE[s/dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==/$body.access_token/]
 // TESTRESPONSE[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/]
 
 The refresh token can now also be immediately invalidated as shown 
 in the following example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/oauth2/token
 {
   "refresh_token" : "vLBPvmAB6KvwvJZr27cS"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[s/vLBPvmAB6KvwvJZr27cS/$body.refresh_token/]
 // TEST[continued]
 
 The following example invalidates all access tokens and refresh tokens for the
 `saml1` realm immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/oauth2/token
 {
   "realm_name" : "saml1"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The following example invalidates all access tokens and refresh tokens for the
 user `myuser` in all realms immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/oauth2/token
 {
   "username" : "myuser"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 Finally, the following example invalidates all access tokens and refresh tokens
 for the user `myuser` in the `saml1` realm immediately:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 DELETE /_security/oauth2/token
 {
@@ -186,8 +174,6 @@ DELETE /_security/oauth2/token
   "realm_name" : "saml1"
 }
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 [source,js]
 --------------------------------------------------

x-pack/docs/en/rest-api/security/oidc-authenticate-api.asciidoc

@@ -61,7 +61,7 @@ OpenID Connect Provider after a successful authentication, for an {es} access
 token and refresh token to be used in subsequent requests. This example is from 
 an authentication that uses the authorization code grant flow.
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oidc/authenticate
 {
@@ -71,7 +71,6 @@ POST /_security/oidc/authenticate
   "realm" : "oidc1"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[catch:unauthorized]
 
 The following example output contains the access token that was generated in

x-pack/docs/en/rest-api/security/oidc-logout-api.asciidoc

@@ -40,7 +40,7 @@ and
 
 The following example performs logout
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oidc/logout
 {
@@ -48,7 +48,6 @@ POST /_security/oidc/logout
   "refresh_token": "vLBPvmAB6KvwvJZr27cS"
 }
 --------------------------------------------------
-// CONSOLE
 // TEST[catch:unauthorized]
 
 The following example output of the response contains the URI pointing to the

x-pack/docs/en/rest-api/security/oidc-prepare-authentication-api.asciidoc

@@ -65,19 +65,18 @@ parameter is not valid when `realm` is specified
 The following example generates an authentication request for the OpenID Connect
 Realm `oidc1`:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oidc/prepare
 {
   "realm" : "oidc1"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of
 the Authentication Request, as HTTP GET parameters:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "redirect" : "http://127.0.0.1:8080/c2id-login?scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=4dbrihtIAt3wBTwo6DxK-vdk-sSyDBV8Yf0AjdkdT5I&nonce=WaBPH0KqPVdG5HHdSxPRjfoZbXMCicm5v1OiAj0DUFM&client_id=elasticsearch-rp",
@@ -92,7 +91,7 @@ The following example generates an authentication request for the OpenID Connect
 Realm `oidc1`, where the values for the state and the nonce have been generated
 by the client:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oidc/prepare
 {
@@ -101,12 +100,11 @@ POST /_security/oidc/prepare
   "nonce" : "zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of
 the Authentication Request, as HTTP GET parameters:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "redirect" : "http://127.0.0.1:8080/c2id-login?scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=lGYK0EcSLjqH6pkT5EVZjC6eIW5YCGgywj2sxROO&nonce=zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5&client_id=elasticsearch-rp",
@@ -114,13 +112,12 @@ the Authentication Request, as HTTP GET parameters:
   "nonce" : "zOBXLJGUooRrbLbQk5YCcyC8AXw3iloynvluYhZ5"
 }
 --------------------------------------------------
-// TESTRESPONSE
 
 The following example generates an authentication request for a 3rd party
 initiated single sign on, specifying the issuer that should be used for matching
 the appropriate OpenID Connect Authentication realm:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 POST /_security/oidc/prepare
 {
@@ -128,12 +125,11 @@ POST /_security/oidc/prepare
   "login_hint": "this_is_an_opaque_string"
 }
 --------------------------------------------------
-// CONSOLE
 
 The following example output of the response contains the URI pointing to the Authorization Endpoint of the OpenID Connect Provider with all the parameters of
 the Authentication Request, as HTTP GET parameters:
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "redirect" : "http://127.0.0.1:8080/c2id-login?login_hint=this_is_an_opaque_string&scope=openid&response_type=id_token&redirect_uri=https%3A%2F%2Fmy.fantastic.rp%2Fcb&state=4dbrihtIAt3wBTwo6DxK-vdk-sSyDBV8Yf0AjdkdT5I&nonce=WaBPH0KqPVdG5HHdSxPRjfoZbXMCicm5v1OiAj0DUFM&client_id=elasticsearch-rp",

x-pack/docs/en/rest-api/security/put-app-privileges.asciidoc

@@ -86,7 +86,7 @@ been created or updated.
 To add a single privilege, submit a PUT or POST request to the
 `/_security/privilege/<application>/<privilege>` endpoint. For example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /_security/privilege
 {
@@ -102,7 +102,6 @@ PUT /_security/privilege
     }
 }
 --------------------------------------------------
-// CONSOLE
 <1> These strings have significance within the "myapp" application. {es} does not 
     assign any meaning to them.
 <2> The use of a wildcard here (`*`) means that this privilege grants access to 
@@ -113,7 +112,7 @@ PUT /_security/privilege
     wildcard and returns `true`.
 <3> The metadata object is optional.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "myapp": {
@@ -123,13 +122,12 @@ PUT /_security/privilege
   }
 }
 --------------------------------------------------
-// TESTRESPONSE
 <1> When an existing privilege is updated, `created` is set to false.
 
 To add multiple privileges, submit a POST request to the 
 `/_security/privilege/` endpoint. For example:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 PUT /_security/privilege
 {
@@ -148,12 +146,11 @@ PUT /_security/privilege
   }
 }
 --------------------------------------------------
-// CONSOLE
 
 A successful call returns a JSON structure that shows whether the privileges 
 have been created or updated.
 
-[source,js]
+[source,console-result]
 --------------------------------------------------
 {
   "app02": {
@@ -171,4 +168,3 @@ have been created or updated.
   }
 }
 --------------------------------------------------
-// TESTRESPONSE

x-pack/docs/en/rest-api/security/ssl.asciidoc

@@ -80,12 +80,10 @@ certificate, this field has a value of `true`.
 The following example provides information about the certificates on a single
 node of {es}:
 
-[source,js]
+[source,console]
 --------------------------------------------------
 GET /_ssl/certificates
 --------------------------------------------------
-// CONSOLE
-// TEST
 
 The API returns the following results: