Files
projectsend/config/projectsend.php
T
ignacionelson 463e86f82b Refuse an account past the seat count an operator sold
Opening user management on cloud (623ad68) left a managed tenant able to
create staff accounts without limit. This is the other half, and the two
belong in the same release.

max_clients and max_staff_users are numbers the platform sells and does
not enforce — grep finds them only being passed to screens. The
application is the only process that can count against them, so it
accepts the number from the environment and refuses to exceed it. That is
not the same as inventing a plan tier, which is what config/api.php
declines to do when it will not key a rate limit off billing: nothing
here knows what a plan is.

## One definition

staffUsed() and clientUsed() are public and are what the guards read. A
control plane showing "2 of 3 used" from its own query, beside an
application refusing the fourth from a different one, disagrees
eventually — over an inactive account, or a deleted one — and the
disagreement reads as a billing fault rather than a counting one.

## What counts, and the consequences somebody has to explain

An inactive staff account occupies its seat. Excluding it would make
deactivation a way around the cap rather than a way to revoke access,
since reactivating is one click. The cost is an awkward incentive —
deactivating is the safe removal and keeps paying, deleting frees the
seat and asks what happens to the files — and it is better explained than
hidden.

A client awaiting approval does not. Self-registration is open to
strangers, and counting a pending request would let anybody exhaust a
paid limit from the outside, turning a pricing tier into an availability
control. The seat is spent at approval, which is where the guard sits.

A soft-deleted account frees its seat, though not its address —
AvailableEmailRule holds that until erasure. So a seat can be free while
re-adding the same person is still refused, which is the address rule
rather than this one.

## Eight doors, eight tests

There is no single User::create() to guard. StaffAccounts::create()
covers both staff controllers, but a promotion takes a staff seat without
creating anything, a demotion takes a client seat, ClientProvisioning
serves registration and LDAP and social sign-in alike, and approval turns
an uncounted request into a counted client.

A cap is only a cap if every door asks, so there is a test per door and
each was verified to fail without its guard — eight red, with the two
"must not change" cases green either way. DownloadAllowance's shape for
DownloadAllowance's reason: the failure mode is one of them quietly not
asking, invisible from everywhere except the door that forgot.

projectsend:admin is deliberately uncapped and has a test saying so. It
is the recovery path, and anyone who can run it can also edit the
environment the cap comes from.
2026-08-27 02:31:12 -03:00

143 lines
5.5 KiB
PHP

<?php
use App\Modules\Platform\Capabilities\Edition;
return [
/*
|--------------------------------------------------------------------------
| Edition
|--------------------------------------------------------------------------
|
| Which edition this installation runs as. Edition is configuration, not a
| code branch: every behavioural difference between editions must flow
| through the capability registry, never through ad-hoc edition checks.
|
| Supported: "community", "cloud"
|
*/
'edition' => Edition::from((string) env('PROJECTSEND_EDITION', 'community')),
/*
|--------------------------------------------------------------------------
| Uploads
|--------------------------------------------------------------------------
|
| Where a chunked upload's parts wait while the transfer is running,
| before they are assembled onto the storage disk. Leave this unset:
| it exists so the test suite can give each parallel worker its own
| directory, since parts are real files on a real path rather than a
| faked disk, and session ids restart at 1 in every worker's database.
|
*/
/*
|--------------------------------------------------------------------------
| Platform seats
|--------------------------------------------------------------------------
|
| How many staff accounts and how many clients this installation may
| hold. Unset means unlimited, which is every self-hosted install: this
| exists for a managed one, where the operator sold a number and the
| application is the only process that can actually count against it.
|
| An operator stating the installation's own limit is not the same as
| the application inventing a plan tier — the distinction config/api.php
| draws when it declines to key a rate limit off billing. Nothing here
| knows what a plan is; it accepts a number and refuses to exceed it.
|
*/
'platform' => [
'max_staff_users' => env('PROJECTSEND_PLATFORM_MAX_STAFF_USERS'),
'max_clients' => env('PROJECTSEND_PLATFORM_MAX_CLIENTS'),
],
'uploads' => [
'parts_path' => env('UPLOAD_PARTS_PATH'),
],
/*
|--------------------------------------------------------------------------
| Chunked upload part size (MB)
|--------------------------------------------------------------------------
|
| Each resumable-upload part travels as one request of this size;
| web-server/PHP body limits only need to cover a single part.
|
*/
'upload_part_size_mb' => 20,
/*
|--------------------------------------------------------------------------
| CAPTCHA
|--------------------------------------------------------------------------
|
| Two things live here rather than in the settings store, for two
| different reasons.
|
| "disabled" is an escape hatch: a wrong secret key cannot lock anybody
| out (see CaptchaResult), but an operator who has managed it some other
| way needs a fix that touches no database and needs no working login.
|
| The managed keys are the platform's own, applied to every tenant on
| cloud and absent everywhere else. In config rather than the tenant
| database so a database dump never carries our credential, and so
| rotating it is one fleet-wide change instead of a migration. They do
| nothing without Capability::CaptchaManagedKeys.
|
*/
'captcha' => [
'disabled' => (bool) env('PROJECTSEND_CAPTCHA_DISABLED', false),
'managed' => [
'provider' => env('PROJECTSEND_CAPTCHA_MANAGED_PROVIDER'),
'site_key' => env('PROJECTSEND_CAPTCHA_MANAGED_SITE_KEY'),
'secret_key' => env('PROJECTSEND_CAPTCHA_MANAGED_SECRET_KEY'),
'score_threshold' => (float) env('PROJECTSEND_CAPTCHA_MANAGED_SCORE_THRESHOLD', 0.5),
],
],
/*
|--------------------------------------------------------------------------
| Release identity
|--------------------------------------------------------------------------
|
| Per-release facts that ship with the code. Not settings: they never
| vary per install or tenant.
|
*/
'version' => '2.2.0',
/*
|--------------------------------------------------------------------------
| Official links
|--------------------------------------------------------------------------
*/
// Read through App\Modules\Platform\OfficialLinks rather than
// directly: which of the two front doors "website" means, and whether
// the donation link is offered at all, both depend on the edition.
'links' => [
'website' => 'https://www.projectsend.org/',
// The hosted service's own front door. A managed installation
// links here instead — including from the "Powered by" line on
// client-facing pages and outgoing email.
'website_cloud' => 'https://www.projectsend.cloud/',
// Where this code lives, and the same repository
// CheckForUpdatesCommand asks for the latest release. v1 remains
// available at github.com/projectsend/legacy.
'source' => 'https://github.com/projectsend/projectsend',
'open_collective' => 'https://opencollective.com/projectsend',
// Kept identical to the invitation update.sh prints when an update
// finishes — the two are the same offer, made in the terminal and
// then again on the screen the administrator lands on.
'discord' => 'https://discord.gg/VT9n6cyvXT',
],
];