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.
Summary:
- Fixing port allocation in TestServer
- Extending logging in the Billing test
- Fixing negative rowIds support for add/remove actions
- Making FormulaEditor and CardView tests less flacky
Test Plan: Existing
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz, dsagal
Differential Revision: https://phab.getgrist.com/D4280
Start documenting the databases including:
* document ACL and other tables
* Permissions
* Groups, secrets, and other tables
---------
Co-authored-by: jordigh <jordigh@octave.org>
When rewriting 1a64910be3, I
accidentally left a stray reference to docker-runner.mjs in there.
Since this file doesn't exist anymore, this prevents Docker builds
from happening.
This adds an endpoint for the admin user to be able to signal to a
controlling process to restart the server. This is intended for
`docker-runner.mjs`.
This is a new entrypoint, mostly intended for Docker, so we have one
simple process controlling the main Grist process. The purpose of this
is to be able to make Grist easily restartable with a new environment.
Summary:
fixSiteProducts was always called with a dry option.
This option was just added for debuging test failure, it should
have been removed.
Test Plan:
Manual.
- on grist core, prepare site with `teamFree` product
- then to recreate run the previous version as
`GRIST_SINGLE_ORG=cool-beans GRIST_DEFAULT_PRODUCT=Free npm start`
- then to confirm it is fixed, run the same command as above
Site should be changed from `teamFree` to `Free`.
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D4276
The HomeDBManager remains the exposed class to the other parts of the code: any module under gen-server/lib/homedb like UsersManager is intended to be used solely by HomeDBManager, and in order to use their methods, an indirection has to be created to pass through HomeDBManager.
Summary:
For non-owners, the timing section of Document Settings is now disabled.
For non-editors, the "Reload" section is disabled.
Test Plan: Added a test case for timing being disabled.
Reviewers: jarek
Reviewed By: jarek
Differential Revision: https://phab.getgrist.com/D4275
Summary:
After release on 2024-06-12 (1.1.15) the GRIST_DEFAULT_PRODUCT env variable wasn't respected by the
method that started the server in single org mode. In all deployments (apart from saas), the default product
used for new sites is set to `Free`, but the code that starts the server enforced `teamFree` product.
This change adds a fix routine that fixes this issue by rewriting team sites from `teamFree` product to `Free`
product only if:
- The default product is set to `Free`
- The deployment type is something other then 'saas'.
Additionally there is a test that will fail after 2024.10.01, as this fix should be removed before this date.
Test Plan: Added test
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D4272
Summary: The GRIST_DEFAULT_PRODUCT wasn't used for grist-ee, now it is respected.
Test Plan:
I've build grist-ee docker image from github and run it using our instruction (both for recreating the issue and confirming it is fixed)
```
docker run -p 8484:8484 \
-v $PWD:/persist \
-e GRIST_SESSION_SECRET=invent-a-secret-here \
-e GRIST_SINGLE_ORG=cool-beans
-it gristlabs/grist-ee
```
For grist-core I recreated/confirmed it is fixed it just by `GRIST_SINGLE_ORG=team npm start` in the core folder.
I also created some team sites using stubbed UI and confirmed that they were using the GRIST_DEFAULT_PRODUCT product.
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D4271
Summary:
- lookupOne/lookupRecords explain `sort_by` param better, and
link to more detailed article.
- Incorporate a typo fix from Help Center
- Fix the omission of TASTEME never having been documented.
Test Plan: Corresponding update to Help Center can be reviewed at https://github.com/gristlabs/grist-help/pull/351
Reviewers: jarek
Reviewed By: jarek
Subscribers: jarek
Differential Revision: https://phab.getgrist.com/D4269
Summary:
- Makes EE decide which ActivationPage to use
- Makes ProductUpgrades use core implementation if not activated
- Changes banners to proxy to core implementation if EE not activated
- [Fix] Enables new site creation in EE as in Core:
- Core enables people to freely create new team sites.
- Enterprise currently redirects to the pricing page.
- This enables enterprise to also create team sites, instead of
redirecting.
Test Plan: Manually test in EE, unit tests in Jenkins
Reviewers: paulfitz, jordigh
Reviewed By: paulfitz
Differential Revision: https://phab.getgrist.com/D4264
Summary:
CheckUpdateAPI is now storing client's installation id in a new field called 'deploymentId'.
Previously it was using installationId which is reserved (and overriden) by the home server.
Test Plan: Existing and manual
Reviewers: paulfitz
Reviewed By: paulfitz
Subscribers: paulfitz
Differential Revision: https://phab.getgrist.com/D4268
Jordi Gutiérrez Hermoso
Paul Fitzpatrick
CamilleLegeron
Paul Janzen
Roman Holinec
Riccardo Polignieri
Spoffy
Jarosław Sadziński
github-actions[bot]
Franček Prijatelj
Leslie H
Florent
Dmitry S
Spoffy