Skip to content

Fix #4774: REST registration follows Wekan's setting - #6598

Closed
AhmedLukman wants to merge 1 commit into
wekan:mainfrom
AhmedLukman:fix/rest-registration
Closed

Fix #4774: REST registration follows Wekan's setting#6598
AhmedLukman wants to merge 1 commit into
wekan:mainfrom
AhmedLukman:fix/rest-registration

Conversation

@AhmedLukman

Copy link
Copy Markdown

Summary

  • make POST /users/register follow Wekan's disableRegistration setting
  • stop treating Meteor useraccounts' internal forbidClientAccountCreation flag as Wekan's public registration policy

Problem

The useraccounts package keeps Accounts._options.forbidClientAccountCreation enabled 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 ReactiveCache and reject REST registration only when disableRegistration is explicitly enabled.

Verification

  • node --check server/apiAuthRoutes.js
  • node tests/run-node-suites.cjs loginBruteForceEnumerationWiring apiLogout
  • production meteor build .build --directory
  • isolated live Wekan and MongoDB test:
    • registration enabled: HTTP 200 with user ID and token
    • returned token authenticated through GET /api/user
    • registration disabled: HTTP 403
    • blocked request created no user

Fixes #4774

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.
@xet7

xet7 commented Aug 15, 2026

Copy link
Copy Markdown
Member

@AhmedLukman

This does not fix Docker. But this helped to find unrelated bug, thanks ! You can read about it later at WeKan changelog.

@xet7 xet7 closed this Aug 15, 2026
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 !
@AhmedLukman

Copy link
Copy Markdown
Author

@xet7 Thanks. While retesting /users/register against the official ghcr.io/wekan/wekan:v10.97 image, I found a separate startup regression.

The unmodified v10.97 container exits before opening its HTTP port with:

Error: Cannot find module
"/node_modules/meteor/email/node_modules/nodemailer-openpgp/lib/nodemailer-openpgp.js"

This appears related to commit d6e21202f, where nodemailer-openpgp and openpgp are classified as unreachable and removed. Meteor’s email package loads nodemailer-openpgp during startup.

I confirmed this with a disposable local v10.97 image that restored only those two directories from v10.96. After that:

  • Wekan started successfully.
  • POST /users/register returned HTTP 200 with a user ID and token.
  • The returned token successfully authenticated GET /api/user.

I directly verified the official Linux/amd64 image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

API /users/register does not work in docker container - HTTP/1.1 403 Forbidden

2 participants