This is an automated email from the ASF dual-hosted git repository.
mmerli pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-pulsar.git
The following commit(s) were added to refs/heads/master by this push:
new 76fb8dc Fix a few links in security pages (#2134)
76fb8dc is described below
commit 76fb8dcdf27e43dbd4f06f68cf823eedcb73e1cf
Author: Sijie Guo <guosi...@gmail.com>
AuthorDate: Wed Jul 11 10:14:51 2018 -0700
Fix a few links in security pages (#2134)
*Motivation*
A few links use `../..` for locating pages in same `security` category,
which are wrong.
*Solution*
Change `../..` to `..`
---
site/docs/latest/security/authorization.md | 6 +++---
site/docs/latest/security/extending.md | 2 +-
site/docs/latest/security/tls.md | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/site/docs/latest/security/authorization.md
b/site/docs/latest/security/authorization.md
index db09685..c0c58ee 100644
--- a/site/docs/latest/security/authorization.md
+++ b/site/docs/latest/security/authorization.md
@@ -24,11 +24,11 @@ tags: [admin, authentication, authorization, athenz, tls,
java, cpp]
-->
-In Pulsar, the [authentication
provider](../../overview#authentication-providers) is charged with properly
identifying clients and
-associating them with [role tokens](../../overview#role-tokens).
*Authorization* is the process that determines *what* clients are able to do.
+In Pulsar, the [authentication provider](../overview#authentication-providers)
is charged with properly identifying clients and
+associating them with [role tokens](../overview#role-tokens). *Authorization*
is the process that determines *what* clients are able to do.
Authorization in Pulsar is managed at the {% popover tenant %} level, which
means that you can have multiple authorization schemes active
-in a single Pulsar instance. You could, for example, create a `shopping`
tenant that has one set of [roles](../../overview#role-tokens)
+in a single Pulsar instance. You could, for example, create a `shopping`
tenant that has one set of [roles](../overview#role-tokens)
and applies to a shopping application used by your company, while an
`inventory` tenant would be used only by an inventory application.
{% include message.html id="properties_multiple_clusters" %}
diff --git a/site/docs/latest/security/extending.md
b/site/docs/latest/security/extending.md
index d32043f..e4f1f4f 100644
--- a/site/docs/latest/security/extending.md
+++ b/site/docs/latest/security/extending.md
@@ -31,7 +31,7 @@ Pulsar provides a way to use custom authentication and
authorization mechanisms
## Authentication
Pulsar support mutual TLS and Athenz authentication plugins, and these can be
used as described
-in [Security](../../overview).
+in [Security](../overview).
It is possible to use a custom authentication mechanism by providing the
implementation in the
form of two plugins one for the Client library and the other for the Pulsar
Broker to validate
diff --git a/site/docs/latest/security/tls.md b/site/docs/latest/security/tls.md
index 35ae533..f343eee 100644
--- a/site/docs/latest/security/tls.md
+++ b/site/docs/latest/security/tls.md
@@ -33,7 +33,7 @@ To encrypt communication, it is recommended to configure all
the Apache Pulsar c
TLS can be configured for encryption or authentication. You may configure just
TLS encryption
(by default TLS encryption includes certificate authentication of the server)
and independently choose a separate mechanism
-for client authentication, e.g. TLS, [Athenz](../../athenz), etc. Note that
TLS encryption, technically speaking, already enables
+for client authentication, e.g. TLS, [Athenz](../athenz), etc. Note that TLS
encryption, technically speaking, already enables
1-way authentication in which the client authenticates the server certificate.
So when referring to TLS authentication, it is really
referring to 2-way authentication in which the broker also authenticates the
client certificate.
@@ -105,7 +105,7 @@ At this point, you should have a `broker-cert.pem` and
`broker-key.pem` file. Th
To create a client certificate, repeat the steps in the previous section, but
did create `client-cert.pem` and `client-key.pem` files instead.
-For the client common name, you need to use a string that you intend to use as
the [role token](#role-tokens) for this client, though it doesn't need to match
the client hostname.
+For the client common name, you need to use a string that you intend to use as
the [role token](../overview#role-tokens) for this client, though it doesn't
need to match the client hostname.
## Configure the broker for TLS
