Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Matrix
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Container Registry
Model registry
Operate
Environments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
TeDomum
Matrix
Commits
833db2d9
Commit
833db2d9
authored
6 years ago
by
Richard van der Hoff
Browse files
Options
Downloads
Patches
Plain Diff
consent tracking docs
parent
e7598b66
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
docs/consent_tracking.md
+152
-0
152 additions, 0 deletions
docs/consent_tracking.md
docs/privacy_policy_templates/README.md
+0
-23
0 additions, 23 deletions
docs/privacy_policy_templates/README.md
docs/server_notices.md
+2
-2
2 additions, 2 deletions
docs/server_notices.md
with
154 additions
and
25 deletions
docs/consent_tracking.md
0 → 100644
+
152
−
0
View file @
833db2d9
Support in Synapse for tracking agreement to server terms and conditions
========================================================================
Synapse 0.30 introduces support for tracking whether users have agreed to the
terms and conditions set by the administrator of a server - and blocking access
to the server until they have.
There are several parts to this functionality; each requires some specific
configuration in
`homeserver.yaml`
to be enabled.
Note that various parts of the configuation and this document refer to the
"privacy policy": agreement with a privacy policy is one particular use of this
feature, but of course adminstrators can specify other terms and conditions
unrelated to "privacy" per se.
Collecting policy agreement from a user
---------------------------------------
Synapse can be configured to serve the user a simple policy form with an
"accept" button. Clicking "Accept" records the user's acceptance in the
database and shows a success page.
To enable this, first create templates for the policy and success pages.
These should be stored on the local filesystem.
These templates use the
[
Jinja2
](
http://jinja.pocoo.org
)
templating language,
and the
`privacy_policy_templates`
subdirectory of this
`docs`
directory gives
examples of the sort of thing that can be done.
Note that the templates must be stored under a name giving the language of the
template - currently this must always be
`en`
(for "English");
internationalisation support is intended for the future.
The template for the policy itself should be versioned - for example
`1.0.html`
. The version of the policy which the user has agreed to is stored in
the database.
Once the templates are in place, make the following changes to
`homeserver.yaml`
:
1.
Add a
`user_consent`
section, which should look like:
```yaml
user_consent:
template_dir: privacy_policy_templates
version: 1.0
```
`template_dir` points to the directory containing the policy
templates. `version` defines the version of the policy which will be served
to the user. In the example above, Synapse will serve
`privacy_policy_templates/en/1.0.html`.
2.
Add a
`form_secret`
setting at the top level:
```yaml
form_secret: "<unique secret>"
```
This should be set to an arbitrary secret string (try `pwgen -y 30` to
generate suitable secrets).
More on what this is used for below.
3.
Add
`consent`
wherever the
`client`
resource is currently enabled in the
`listeners`
configuration. For example:
```
listeners:
- port: 8008
resources:
- names:
- client
- consent
```
Finally, ensure that
`jinja2`
is installed. If you are using a virtualenv, this
should be a matter of
`pip install Jinja2`
. On debian, try
`apt-get install
python-jinja2`
.
Once this is complete, and the server has been restarted, try visiting
`https://<server>/_matrix/consent`
. If configuration has been done correctly,
this should give an error "Missing string query parameter 'u'". It is now
possible to manually construct URIs where users can give their consent.
Constructing the consent URI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It may be useful to manually construct the "consent URI" for a given user - for
instance, in order to send them an email asking them to consent. To do this,
take the base `https://<server>/_matrix/consent` URL and add the following
query parameters:
* `u`: the user id of the user. This can either be a full MXID
(`@user:server.com`) or just the localpart (`user`).
* `h`: hex-encoded HMAC-SHA256 of `u` using the `form_secret` as a key. It is
possible to calculate this on the commandline with something like:
```bash
echo -n '<user>' | openssl sha256 -hmac '<form_secret>'
```
This should result in a URI which looks something like:
`https://<server>/_matrix/consent?u=<user>&h=68a152465a4d...`.
Sending users a server notice asking them to agree to the policy
----------------------------------------------------------------
It is possible to configure Synapse to send a [server
notice](server_notices.md) to anybody who has not yet agreed to the current
version of the policy. To do so:
* ensure that the consent resource is configured, as in the previous section
* ensure that server notices are configured, as in [server_notices.md].
* Add `server_notice_content` under `user_consent` in `homeserver.yaml`. For
example:
```yaml
user_consent:
server_notice_content:
msgtype: m.text
body: >-
Please give your consent to the privacy policy at %(consent_uri)s.
```
Synapse automatically replaces the placeholder `%(consent_uri)s` with the
consent uri for that user.
Blocking users from using the server until they agree to the policy
-------------------------------------------------------------------
Synapse can be configured to block any attempts to join rooms or send messages
until the user has given their agreement to the policy. (Joining the server
notices room is exempted from this).
To enable this, add `block_events_error` under `user_consent`. For example:
```
user_consent:
block_events_error: >-
You can't send any messages until you consent to the privacy policy at
%(consent_uri)s.
```
Synapse automatically replaces the placeholder `%(consent_uri)s` with the
consent uri for that user.
This diff is collapsed.
Click to expand it.
docs/privacy_policy_templates/README.md
deleted
100644 → 0
+
0
−
23
View file @
e7598b66
If enabling the 'consent' resource in synapse, you will need some templates
for the HTML to be served to the user. This directory contains very simple
examples of the sort of thing that can be done.
You'll need to add this sort of thing to your homeserver.yaml:
```
form_secret: <unique but arbitrary secret>
user_consent:
template_dir: docs/privacy_policy_templates
version: 1.0
```
You should then be able to enable the
`consent`
resource under a
`listener`
entry. For example:
```
listeners:
- port: 8008
resources:
- names: [client, consent]
```
This diff is collapsed.
Click to expand it.
docs/server_notices.md
+
2
−
2
View file @
833db2d9
...
...
@@ -4,8 +4,8 @@ Server Notices
'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
channel whereby server administrators can send messages to users on the server.
They are used as part of the communication of
Privacy P
olices (see
[
privacy_policy
.md]), however the intention is that they may also find a use
They are used as part of the communication of
the server p
olices (see
[
consent_tracking
.md]), however the intention is that they may also find a use
for features such as "Message of the day".
This is a feature specific to Synapse, but it uses standard Matrix
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment