Skip to content

feat(ws): allow subdomain wildcards in allowed origins - #177

Merged
MrAlders0n merged 1 commit into
devfrom
feat/ws-origin-wildcard
Sep 28, 2026
Merged

MrAlders0n merged 1 commit into
devfrom
feat/ws-origin-wildcard

Conversation

@MrAlders0n

Copy link
Copy Markdown
Member

Follow-up to #170. websocket.allowed_origins only took exact origins, which doesn't work when a site serves its pages from lots of subdomains that keep growing. This lets you write https://*.example.com instead of listing each one.

The websocket library already matches these patterns, so the only real change is in validateOrigin. The one new form it accepts is *. as the whole leftmost label with at least two labels after it. Anything else with *, ?, [, ] or \ is still rejected (https://*, *.com, a*.example.com, x.*.example.com, and so on).

Matching behaviour:

  • https://*.example.com matches sub.example.com and a.b.example.com, case-insensitively
  • it does not match the apex example.com, so list that separately if you need it
  • scheme and port stay exact

Default-off. Configs without a wildcard behave the same as before. CORS is untouched.

Tests: config validation cases for the accepted and rejected forms, plus real handshake cases in TestAllowedOrigins (subdomains get through, while apex, lookalike hosts, wrong scheme and wrong port get 403). No API changes, so swagger is unchanged.

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.

1 participant