[ARVADOS] updated: 2.1.0-1142-g1c5a21a73
Git user
git at public.arvados.org
Tue Aug 3 21:27:46 UTC 2021
Summary of changes:
doc/api/keep-web-urls.html.textile.liquid | 4 ++--
doc/install/install-manual-prerequisites.html.textile.liquid | 10 ++++++----
lib/config/config.default.yml | 8 ++++----
lib/config/generated_config.go | 8 ++++----
4 files changed, 16 insertions(+), 14 deletions(-)
via 1c5a21a73b2e5281cea17db4ae5f4d367dee1ee4 (commit)
from 6160b7425d9da6cc9d245b7cc754e81427f8ac9c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
commit 1c5a21a73b2e5281cea17db4ae5f4d367dee1ee4
Author: Ward Vandewege <ward at curii.com>
Date: Tue Aug 3 17:26:30 2021 -0400
17591: address review feedback.
Arvados-DCO-1.1-Signed-off-by: Ward Vandewege <ward at curii.com>
diff --git a/doc/api/keep-web-urls.html.textile.liquid b/doc/api/keep-web-urls.html.textile.liquid
index 1770a259b..ed0bde813 100644
--- a/doc/api/keep-web-urls.html.textile.liquid
+++ b/doc/api/keep-web-urls.html.textile.liquid
@@ -14,7 +14,7 @@ Files served by @keep-web@ can be rendered directly in the browser, or @keep-web
When serving files that will render directly in the browser, it is important to properly configure the keep-web service to migitate cross-site-scripting (XSS) attacks. A HTML page can be stored in a collection. If an attacker causes a victim to visit that page through Workbench, the HTML will be rendered by the browser. If all collections are served at the same domain, the browser will consider collections as coming from the same origin, which will grant access to the same browsing data (cookies and local storage). This would enable malicious Javascript on that page to access Arvados on behalf of the victim.
-This can be mitigated by having separate domains for each collection, or limiting preview to circumstances where the collection is not accessed with the user's regular full-access token. For cluster administrators that understand the risks, this protection can also be turned off.
+This can be mitigated by having separate domains for each collection, or limiting preview to circumstances where the collection is not accessed with the user's regular full-access token. For clusters where this risk is acceptable, this protection can also be turned off by setting the @Collections/TrustAllContent@ configuration flag to true, see the "configuration reference":../admin/config.html for more detail.
The following "same origin" URL patterns are supported for public collections and collections shared anonymously via secret links (i.e., collections which can be served by keep-web without making use of any implicit credentials like cookies). See "Same-origin URLs" below.
@@ -82,4 +82,4 @@ When a client passes a token in the URL, keep-web sends a redirect response plac
This mainly affects Workbench's ability to show inline content, so it should be taken into account when configuring both services' URL schemes.
-You can read more about the definition of a _same-site_ request at the "RFC 6265bis-03 page":https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2
\ No newline at end of file
+You can read more about the definition of a _same-site_ request at the "RFC 6265bis-03 page":https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2
diff --git a/doc/install/install-manual-prerequisites.html.textile.liquid b/doc/install/install-manual-prerequisites.html.textile.liquid
index 77b46358b..084f32e02 100644
--- a/doc/install/install-manual-prerequisites.html.textile.liquid
+++ b/doc/install/install-manual-prerequisites.html.textile.liquid
@@ -142,13 +142,13 @@ You may also use a different method to pick the cluster identifier. The cluster
h2(#dnstls). DNS entries and TLS certificates
-The following services are normally public-facing and require DNS entries and corresponding TLS certificates. Get certificates from your preferred TLS certificate provider. We recommend using "Let's Encrypt":https://letsencrypt.org/. You can run several services on same node, but each distinct hostname requires a valid, matching TLS certificate.
+The following services are normally public-facing and require DNS entries and corresponding TLS certificates. Get certificates from your preferred TLS certificate provider. We recommend using "Let's Encrypt":https://letsencrypt.org/. You can run several services on the same node, but each distinct DNS name requires a valid, matching TLS certificate.
-This guide uses the following hostname conventions. A later part of this guide will describe how to set up Nginx virtual hosts.
+This guide uses the following DNS name conventions. A later part of this guide will describe how to set up Nginx virtual hosts.
<div class="offset1">
table(table table-bordered table-condensed).
-|_. Function|_. Hostname|
+|_. Function|_. DNS name|
|Arvados API|@ClusterID.example.com@|
|Arvados Git server|git. at ClusterID.example.com@|
|Arvados Webshell|webshell. at ClusterID.example.com@|
@@ -163,7 +163,9 @@ _and_
collections. at ClusterID.example.com@ (see the "keep-web install docs":install-keep-web.html)|
</div>
-Setting up Arvados is easiest when Wildcard TLS and wildcard DNS are available. It is also possible to set up Arvados without wildcard TLS and DNS. The table below lists the required TLS certificates and DNS hostnames in each scenario.
+Setting up Arvados is easiest when Wildcard TLS and wildcard DNS are available. It is also possible to set up Arvados without wildcard TLS and DNS, but not having a wildcard for @keep-web@ (i.e. not having *.collections. at ClusterID.example.com@) comes with a tradeoff: it will disable some features that allow users to view Arvados-hosted data in their browsers. More information on this tradeoff caused by the CORS rules applied by modern browsers is available in the "keep-web URL pattern guide":../api/keep-web-urls.html.
+
+The table below lists the required TLS certificates and DNS names in each scenario.
<div class="offset1">
table(table table-bordered table-condensed).
diff --git a/lib/config/config.default.yml b/lib/config/config.default.yml
index 64d59f2c0..3ce160776 100644
--- a/lib/config/config.default.yml
+++ b/lib/config/config.default.yml
@@ -520,10 +520,10 @@ Clusters:
# WebDAV would have to expose XSS vulnerabilities in order to
# handle the redirect (see discussion on Services.WebDAV).
#
- # This setting has no effect in the recommended configuration,
- # where the WebDAV is configured to have a separate domain for
- # every collection; in this case XSS protection is provided by
- # browsers' same-origin policy.
+ # This setting has no effect in the recommended configuration, where the
+ # WebDAV service is configured to have a separate domain for every
+ # collection and XSS protection is provided by browsers' same-origin
+ # policy.
#
# The default setting (false) is appropriate for a multi-user site.
TrustAllContent: false
diff --git a/lib/config/generated_config.go b/lib/config/generated_config.go
index a7aebe638..4a726d1ec 100644
--- a/lib/config/generated_config.go
+++ b/lib/config/generated_config.go
@@ -526,10 +526,10 @@ Clusters:
# WebDAV would have to expose XSS vulnerabilities in order to
# handle the redirect (see discussion on Services.WebDAV).
#
- # This setting has no effect in the recommended configuration,
- # where the WebDAV is configured to have a separate domain for
- # every collection; in this case XSS protection is provided by
- # browsers' same-origin policy.
+ # This setting has no effect in the recommended configuration, where the
+ # WebDAV service is configured to have a separate domain for every
+ # collection and XSS protection is provided by browsers' same-origin
+ # policy.
#
# The default setting (false) is appropriate for a multi-user site.
TrustAllContent: false
-----------------------------------------------------------------------
hooks/post-receive
--
More information about the arvados-commits
mailing list