The class was only checking whether or not a specific token exists in
moodle, and it should ensure that it has access to the right permissions
Reported by: @elena61
This can be used by setting up HAPROXY_CONF in dd.conf, which will
determine which config file will be used.
We also add haproxy.proxy-protocol.conf which is cleaner than
haproxy.conf and allows the PROXY protocol on certain ports.
With this setup it is possible to e.g. run DD without a public IPv4
address by proxying it from an edge server.
When we improved the update process, we introduced a deadlock when not
having docker.
By separating update from repo-update we can differentiate those cases:
- update: full update of an existing installation
- repo-update: bring repository to latest stand
When introducing typing, we erroneously started passing an empty parent
Id instead of None, and the underlying Keycloak library failed to create
the groups.
Closes#15
This was a bad design choice since it doesn't allow us to easily manage
the intended plugin version and therefore keep them up to date.
As a short-term mechanism, we change the used variables to have the
_OVERRIDE suffix and default in dd-ctl to the actual URLs, while also
removing them from dd.conf.sample.
This solves the issue in both current and future installations; in a
near future we want to have these dependencies in a .tsv file where they
can easily be managed.
From minio's documentation:
- MINIO_ACCESS_KEY and MINIO_SECRET_KEY are deprecated in lieu of
MINIO_ROOT_USER and MINIO_ROOT_PASSWORD respectively
- In order to rotate secrets we only need to change
MINIO_ROOT_{USER,PASSWORD}
Using this commit and the previous one affecting keycloak we can use
per-instance keys as opposed to the current state.
In order to achieve this, AVATARS_ACCESS_KEY and AVATARS_SECRET_KEY must
be set to the desired values.
The only guidelines as to how to generate ACCESS_KEY and SECRET_KEY are:
> Specify a unique, random, and long string for both the ACCESSKEY and
> SECRETKEY. Your organization may have specific internal or regulatory
> requirements around generating values for use with access or secret keys.
See:
- https://docs.min.io/minio/baremetal/reference/minio-server/minio-server.html#envvar.MINIO_ACCESS_KEY
- https://docs.min.io/minio/baremetal/security/minio-identity-management/user-management.html
This was needed because previously the DEFAULT_SERVER_URL was hardcoded
in the compiled keycloak module and that URL has changed.
For consistency sso-admin uses the same environment variables (except it
needs AVATARS_SERVER_HOST instead of AVATARS_SERVER_URL).
node_modules needs proper permissions on image build and the Nextcloud
queue on run-time.
We also realised the user must be www-data for compatibility with the NC
image.
The endpoints for the mail integration are added here.
The ThirdPartyIntegrationKeys class in admin.lib.keys is intended to be
used on both the sending and receiving part of communications.
Implementations in other languages should closely follow its design, so
we are sure communication happens as it is expected.
Broadly speaking:
- Each party receives a name (DD is always "DD") that is well-known to
all communicating parties
- Each party sets up an endpoint sharing their public key in JWK format
See: https://datatracker.ietf.org/doc/html/rfc7517
And the many JWK implementations around. This class uses python-jose's
- In a key_store folder, the remote party's public key will be cached
and the local private key will be generated and saved
- Any data exchanged between the two parties must:
- Be first encrypted with the remote party's public key
See: https://datatracker.ietf.org/doc/html/rfc7516
- Then signed with the local party's private key, by adding its
payload to a 'data' claim.
See: https://datatracker.ietf.org/doc/html/rfc7515
- Have an Authorization header with a signed JWT containing the local
party's name as the 'kid' header.
This aids the remote party in deciding which key needs to be used.
Evilham
elena
Jose Antonio Exposito Garcia
Xnet Xnet