Fix #4774: REST registration follows Wekan's setting - #6598
Closed
AhmedLukman wants to merge 1 commit into
Closed
Conversation
The useraccounts package keeps Accounts._options.forbidClientAccountCreation enabled because browser sign-up uses its server method. The REST route treated that internal flag as Wekan's public registration policy and returned 403 even when registration was enabled. Read disableRegistration from ReactiveCache so the REST endpoint follows the Admin Panel setting. Tests: production Meteor build; live enabled and disabled POST /users/register requests; token-authenticated GET /api/user. Fixes wekan#4774.
AhmedLukman
marked this pull request as ready for review
August 15, 2026 13:04
Member
|
This does not fix Docker. But this helped to find unrelated bug, thanks ! You can read about it later at WeKan changelog. |
xet7
added a commit
that referenced
this pull request
Aug 16, 2026
… anyway.
POST /users/register guarded itself with
Accounts._options.forbidClientAccountCreation, which NOTHING IN WEKAN EVER
SETS:
* the only Accounts.config() call, in server/accounts-common.js, sets
loginExpirationInDays and nothing else;
* forbidClientAccountCreation: disableRegistration in config/accounts.js
is passed to AccountsTemplates.configure() - the useraccounts package's
own options object, not Meteor's Accounts;
* and that disableRegistration is only assigned inside an async
Meteor.call('isDisableRegistration') callback that fires AFTER
configure() has run, which the file's own comment already records.
So the condition was always falsy and the endpoint never refused anybody.
Turning registration OFF in the Admin Panel closed the sign-up form and
left POST /users/register creating accounts for whoever asked - on an
instance whose administrator had decided nobody else may join. The setting
is read from where it actually lives now, the same way the
isDisableRegistration Meteor method reads it, and a missing Settings
document still means registration is allowed rather than locking a fresh
instance out.
Every call that reaches the refusal is an attempt, because there is no
legitimate caller once the admin has turned registration off, so it is
recorded and shows in Admin Panel / Problems under authz.register /
SignupBleed.
Found while reviewing PR #6598 by AhmedLukman, filed against #4774 - a 403
nobody could reproduce, and which this line cannot produce. Looking for it
turned up the opposite fault.
Nine tests, four of them negative, on a route that had none at all: that
the setting is read where the Meteor method reads it, that the dead Meteor
option is not consulted again AND is still never set anywhere (so a future
change cannot quietly reintroduce two sources of truth that disagree), that
an enabled instance still creates the user and gets its token, and that no
Settings document does not refuse everybody.
Thanks to AhmedLukman and xet7 !
Author
|
@xet7 Thanks. While retesting The unmodified v10.97 container exits before opening its HTTP port with: This appears related to commit I confirmed this with a disposable local v10.97 image that restored only those two directories from v10.96. After that:
I directly verified the official Linux/amd64 image. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
POST /users/registerfollow Wekan'sdisableRegistrationsettingforbidClientAccountCreationflag as Wekan's public registration policyProblem
The useraccounts package keeps
Accounts._options.forbidClientAccountCreationenabled because browser sign-up uses its server method. The REST route used that internal flag as its registration gate, so it returned HTTP 403 even when registration was enabled in Wekan.Fix
Read the current Wekan settings through
ReactiveCacheand reject REST registration only whendisableRegistrationis explicitly enabled.Verification
node --check server/apiAuthRoutes.jsnode tests/run-node-suites.cjs loginBruteForceEnumerationWiring apiLogoutmeteor build .build --directoryGET /api/userFixes #4774