Separate static content specific to doc content

We mixed together doc content and website content. We don’t need to
version the website content (logos, main site stuff, etc) but the doc
static content (mostly images) should be tied to the markdown that
uses it.

Signed-off-by: Patrick East <east.patrick@gmail.com>
This commit is contained in:
Patrick East
2019-04-24 19:59:23 -07:00
parent 37f003c410
commit c8ea625d65
25 changed files with 23 additions and 10 deletions
+1 -1
View File
@@ -53,4 +53,4 @@ into OPA via the filesystem or well-defined APIs.
## Why use OPA?
{{< figure src="/img/benefits.svg" width="65" caption="Open Policy Agent: before and after" >}}
{{< figure src="benefits.svg" width="65" caption="Open Policy Agent: before and after" >}}
+4 -4
View File
@@ -28,7 +28,7 @@ The following diagram shows this process in more detail.
1. The OPA-enabled software system includes that token as part of the usual `input` to OPA.
1. OPA decodes the JWT token and uses the contents to make policy decisions.
{{< figure src="/img/best-practice-identity-jwt.png" width="60" caption="JSON Web Token flow" >}}
{{< figure src="best-practice-identity-jwt.png" width="60" caption="JSON Web Token flow" >}}
### Updates
The JWT only gets refreshed when the user authenticates; how often that happens is up to the TTL included in the token. When LDAP/AD information changes, those changes will not be seen by OPA until the user authenticates and gets a new JWT.
@@ -58,7 +58,7 @@ Two things happen independently with this kind of LDAP/AD integration.
1. OPA downloads new policy bundles including LDAP/AD
1. OPA-enabled software system asks OPA for policy decisions
{{< figure src="/img/best-practice-identity-bundle.png" width="80" caption="Bundle flow" >}}
{{< figure src="best-practice-identity-bundle.png" width="80" caption="Bundle flow" >}}
### Updates
The lag between an LDAP/AD update and OPA having the update is the sum of the lag for an update between LDAP/AD and the central server and the lag for an update between the central server an OPA. So if LDAP/AD updates every 5 minutes, and OPA pulls an update every 2 minutes, then the total maximum lag is 7 minutes. Unlike the JWT case, it is feasible that a user could perform an action requiring authorization on the OPA-enabled service before OPA has the appropriate LDAP/AD policy, but you can account for that when writing policy and reject any request when there is insufficient data.
@@ -81,7 +81,7 @@ Two things happen independently with this kind of LDAP/AD integration.
1. Synchronizer keeps OPA up to date with LDAP/AD
1. OPA-enabled software system asks OPA for policy decisions
{{< figure src="/img/best-practice-identity-push.png" width="80" caption="Push flow" >}}
{{< figure src="best-practice-identity-push.png" width="80" caption="Push flow" >}}
### Updates
@@ -114,7 +114,7 @@ The key difference here is that every decision requires contacting LDAP/AD. If
1. OPA-enabled service asks OPA for a decision
1. OPA during evaluation asks LDAP/AD for user attributes
{{< figure src="/img/best-practice-identity-remote.png" width="80" caption="Pull flow" >}}
{{< figure src="best-practice-identity-remote.png" width="80" caption="Pull flow" >}}
### Updates
LDAP/AD data is perfectly fresh. There is no lag between an update to LDAP/AD and when OPA sees that update.
+3 -3
View File
@@ -16,7 +16,7 @@ OPAs RESTful APIs use JSON over HTTP so you and your users can integrate OPA
When your service is integrated with OPA, your users will be able author and deploy custom policies that control the behavior of your services policy-enabled features. Furthermore, users can publish data to OPA that is not available to your service about their own deployment context.
{{< figure src="/img/request-response.svg" width="50" caption="OPA's query and decision model" >}}
{{< figure src="request-response.svg" width="50" caption="OPA's query and decision model" >}}
In the future, both your service and its users will be able to register for, and react to, notifications triggered when OPA detects a policy-relevant change.
@@ -30,7 +30,7 @@ When OPA starts for the first time, it will not contain any policies or data. Po
The primary unit of data in OPA is a document, which is similar to a JSON value. Documents typically correspond to single, self-contained objects and are capable of representing both primitive types (strings, numbers, booleans, and null) as well as structured types (objects, and arrays). Documents are created, read, updated, and deleted via OPAs [RESTful HTTP APIs](../rest-api).
{{< figure src="/img/data-model-dependencies.svg" width="70" caption="OPA data model dependencies" >}}
{{< figure src="data-model-dependencies.svg" width="70" caption="OPA data model dependencies" >}}
### Base Documents
@@ -153,7 +153,7 @@ In contrast to base documents, virtual documents embody the results of evaluatin
All documents pushed into OPA or computed by rules are nested under a built-in root document named data.
{{< figure src="/img/data-model-logical.svg" width="70" caption="OPA document structure" >}}
{{< figure src="data-model-logical.svg" width="70" caption="OPA document structure" >}}
Example `data` document:

Before

Width:  |  Height:  |  Size: 183 KiB

After

Width:  |  Height:  |  Size: 183 KiB

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Before

Width:  |  Height:  |  Size: 67 KiB

After

Width:  |  Height:  |  Size: 67 KiB

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Before

Width:  |  Height:  |  Size: 58 KiB

After

Width:  |  Height:  |  Size: 58 KiB

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Before

Width:  |  Height:  |  Size: 175 KiB

After

Width:  |  Height:  |  Size: 175 KiB

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Before

Width:  |  Height:  |  Size: 72 KiB

After

Width:  |  Height:  |  Size: 72 KiB

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 57 KiB

Before

Width:  |  Height:  |  Size: 67 KiB

After

Width:  |  Height:  |  Size: 67 KiB

Before

Width:  |  Height:  |  Size: 91 KiB

After

Width:  |  Height:  |  Size: 91 KiB

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

+15 -2
View File
@@ -1,9 +1,22 @@
{{ $src := .Get "src" | relURL }}
{{ $src := .Get "src" }}
{{ $version := index (split $.Page.File.Path "/") 1 }}
{{/*
TODO: Remove this check once we no longer have doc releases
with non versioned images. As-is just point them to "edge" since
that version will not have the image bundled with the versioned
markdown content.
*/}}
{{ if (hasPrefix $src "/img/") }}
{{ $src = strings.TrimPrefix "/img/" $src }}
{{ $version = "edge" }}
{{ end }}
{{ $relPath := printf "/docs/%s/images/%s" $version $src }}
{{ $caption := .Get "caption" | markdownify }}
{{ $width := .Get "width" | default 50 }}
{{ $alt := cond (isset .Params "caption") $caption (.Get "alt" | markdownify) }}
<figure class="figure">
<img src="{{ $src }}" width="{{ $width }}%">
<img src="{{ $relPath }}" width="{{ $width }}%">
{{ with $caption }}
<figcaption class="has-text-weight-light">