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.
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
The example key shown on the admin panel to users who are not known to be
administrators is generated using a method that is only available in secure
environments. This adds a fallback for insecure environments. The key is less
solid but again, it is just an example, and for an insecure environment.
Tested manually running locally and using a hostname set in /etc/hosts.
This fixes the flaky test in "ViewLayoutCollapse.ts": "fix: should not dispose the instance when drag is cancelled".
The 'mouseenter' event wasn't consistently triggering properly on the drop target (LayoutEditor.ts - line 342) when the mouse was moved onto it.
The change simulates a "drag" over the drop target, moving the mouse into multiple positions over it, seemingly fixing the problem.
This is a small thing, but when visiting the admin, the websocket test
doesn't send valid JSON, which the receiving endpoint expects. This
results in a harmless exception being thrown.
While this test should eventually be modified to be run from the
frontend, for now let's just make a small fix and send valid JSON in
order to avoid that JSON parsing exception.
Grist has for some time supported a sandbox based on pyodide.
It is a bit slower to start than the gvisor-based sandbox, but
can run in situations where it can't. Until now it hasn't been
easy to use when running Grist as a container, since the support
files weren't included. This change rectifies that omission.
Nothing changes by default. But now if you start Grist as a container
and set `GRIST_SANDBOX_FLAVOR=pyodide`, it should work rather than
fail.
Summary:
Dropdown conditions can now reference a `user` variable, similar to the
one available in Access Rules.
Test Plan: Browser test.
Reviewers: jarek, paulfitz
Reviewed By: jarek, paulfitz
Differential Revision: https://phab.getgrist.com/D4255
