luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

Docs: Fix broken link (#12192) 

* Docs: Fix broken link

What does this PR do

Fix dead or broken links in this docs page, making navigation easy for others.

* fixing broken link

* fixing broken links
This commit is contained in:
SaintMalik 2021-07-28 21:18:54 +01:00 committed by GitHub
parent 5f57fa205f
commit 4223ddf6fd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/docs/concepts/client-count.mdx
View File

@ -31,7 +31,7 @@ There can be many different types of clients that authenticate and communicate w
## How do Clients work in Vault?
When anything authenticates to Vault, be it a user, application, machine, etc., it is associated with a unique **entity** within the [Vault identity system](https://www.vaultproject.io/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies ([list below](/what-is-a-client#authentication-methods-and-how-they-re-counted-in-vault)), each entity is created or verified during authorization. There are scenarios where tokens can be created outside of the identity system, without an associated entity. In this scenario, these tokens are considered **clients** (for production usage, it should be rare to have any tokens created outside any identity systems).
When anything authenticates to Vault, be it a user, application, machine, etc., it is associated with a unique **entity** within the [Vault identity system](https://www.vaultproject.io/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies ([list below](#authentication-methods-and-how-they-re-counted-in-vault)), each entity is created or verified during authorization. There are scenarios where tokens can be created outside of the identity system, without an associated entity. In this scenario, these tokens are considered **clients** (for production usage, it should be rare to have any tokens created outside any identity systems).
## But wait, there’s more...

2
website/content/docs/concepts/password-policies.mdx
View File

@ -237,7 +237,7 @@ If we do this for uppercase letters as well as numbers, then we get a combined p
It should be noted that this probability curve only applies to this specific policy. To understand the
performance characteristics of a given policy, you should run your policy with the
[`generate`](/api-docs/system/policies-password.mdx) endpoint to see how much time the policy takes to
[`generate`](/api-docs/system/policies-password) endpoint to see how much time the policy takes to
produce passwords.
</details>

2
website/content/docs/internals/security.mdx
View File

@ -118,7 +118,7 @@ client), the highest access level permitted is used. For example, if the
"ops" policy permits read access to the "ops/" path, then the user gets the
union of those. Policy is matched using the most specific defined policy, which
may be an exact match or the longest-prefix match glob pattern. See
[Policy Syntax](../concepts/policies.mdx#policy-syntax) for more details.
[Policy Syntax](../concepts/policies#policy-syntax) for more details.
Certain operations are only permitted by "root" users, which is a distinguished
policy built into Vault. This is similar to the concept of a root user on a