Having it checked in to git caused problems with Grist Desktop and
Grist Static because their build processes expected to have nothing
there, as well as interfering with checking out Grist Core as a
submodule.
So we do this instead.
Now that we *have* to have something in the ext directory, we need to
either restore the external ext or the default OSS ext depending on
which build we are doing.
Summary: Change "bien" to "beaucoup" and add a space before the exclamation mark as is usually done in French.
Test Plan: None.
Reviewers: paulfitz
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D4291
Summary: Path for the HomeDbManager has beed updated after merging with core.
Test Plan: Existing
Reviewers: georgegevoian
Reviewed By: georgegevoian
Subscribers: georgegevoian
Differential Revision: https://phab.getgrist.com/D4288
This adds a config file that's loaded very early on during startup.
It enables us to save/load settings from within Grist's admin panel, that affect the startup of the FlexServer.
The config file loading:
- Is type-safe,
- Validates the config file on startup
- Provides a path to upgrade to future versions.
It should be extensible from other versions of Grist (such as desktop), by overriding `getGlobalConfig` in stubs.
----
Some minor refactors needed to occur to make this possible. This includes:
- Extracting config loading into its own module (out of FlexServer).
- Cleaning up the `loadConfig` function in FlexServer into `loadLoginSystem` (which is what its main purpose was before).
Summary:
Some editors do some async work before saving the value (Ref column can add new
records). Those actions were send without bundling, so it wasn't possible to undo those
actions with togheter.
Test Plan: Added new test
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D4285
Summary:
- Adding confirmation dialog when user doesn't want to cancel site
- Changing `Cancel subscription` to `Cancel plan`
- Removing `Pro` from upgrade header on pricing modal
- Better handling situation when there is no default price
- Removing mentions about sprouts program
- Removing cache for stripe plans
Test Plan: Updated tests
Reviewers: georgegevoian
Reviewed By: georgegevoian
Differential Revision: https://phab.getgrist.com/D4273
While the intent was to run tests with it, we don't need it. Instead,
this caused problems because the stubs overrode the intended `ext`
directory and therefore disabled the ext features.
De-escalates to a normal user when the docker image is run as root.
Allows GRIST_DOCKER_USER and GRIST_DOCKER_GROUP to be passed to override the default de-escalation behaviour.
Backwards compatible with previous root installations.
--------
This change adds a new docker_entrypoint.sh, which when run as root de-escalates to the provided user, defaulting to grist:grist. This is similar to the approach used by the official postgres docker image.
To achieve backwards compatibility, it changes ownership of any files in `/persist` to the user it's given at runtime. Since the docker container is typically run as root, this should always work.
If the container is run as a standard user from the very start:
* It's the admin's responsibility to ensure `/persist` is writable by that user.
* `/grist` remains owned by root and is read-only.
Summary:
Version API endpoint wasn't logging telemetry from POST requests. The issue was in registration
order, this endpoint was registered before `expressJson` and it couldn't read json body in the handler.
Test Plan: Added new test
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D4277
This modifies the workflow to build grist-ee images as well as grist,
which is the same image as grist-ee but merely renamed. The original
image built by these workflows is now called grist-oss.
Since we won't be tracking ext/-directory providers via git (e.g. no
submodules), instead we'll do little version-tracking files like this,
to be used by the recent ext-checkout script.
Follow-up of #994. This PR revises the session ID generation logic to improve security in the absence of a secure session secret. It also adds a section in the admin panel "security" section to nag system admins when GRIST_SESSION_SECRET is not set.
Following is an excerpt from internal conversation.
TL;DR: Grist's current implementation generates semi-secure session IDs and uses a publicly known default signing key to sign them when the environment variable GRIST_SESSION_SECRET is not set. This PR generates cryptographically secure session IDs to dismiss security concerns around an insecure signing key, and encourages system admins to configure their own signing key anyway.
> The session secret is required by expressjs/session to sign its session IDs. It's designed as an extra protection against session hijacking by randomly guessing session IDs and hitting a valid one. While it is easy to encourage users to set a distinct session secret, this is unnecessary if session IDs are generated in a cryptographically secure way. As of now Grist uses version 4 UUIDs as session IDs (see app/server/lib/gristSessions.ts - it uses shortUUID.generate which invokes uuid.v4 under the hood). These contain 122 bits of entropy, technically insufficient to be considered cryptographically secure. In practice, this is never considered a real vulnerability. To compare, RSA2048 is still very commonly used in web servers, yet it only has 112 bits of security (>=128 bits = "secure", rule of thumb in cryptography). But for peace of mind I propose using crypto.getRandomValues to generate real 128-bit random values. This should render session ID signing unnecessary and hence dismiss security concerns around an insecure signing key.
