Skip to content

Conversation

sandhose
Copy link
Member

@sandhose sandhose commented Feb 17, 2025

This does a few things:

  • it exposes the IP address and user agent of the browser in the policy
  • it refactors a bit the policy to share logic between policies under the common package
  • it adds helpers to match a string against 'constraints' (literals, regexes, substrings)
  • it adds logic in the policy to ban IPs and user agents during auth grants and user registrations
  • it makes it possible to allow/ban email addresses using this new 'constraints' logic, making it possible to ban email bases on a regex

The user-visible feedback isn't great (not translated, a bit verbose), but it's fine

image

Here is what's now possible:

policy:
  data:
    # Restrict what email addresses can be added to a user
    emails:
      # If specified, the email address *must* match one of the allowed addresses.
      # If unspecified, all email addresses are allowed.
      allowed_addresses:
        # Exact emails that are allowed
        literals: ["[email protected]", "[email protected]"]
        # Regular expressions that match allowed emails
        regexes: ["@example\\.com$"]
        # Suffixes that match allowed emails
        suffixes: ["@example.com"]
        # Also supported, but don't really make sense in this context
        #prefixes: []
        #substrings: []

      # If specified, the email address *must not* match one of the banned addresses.
      # If unspecified, all email addresses are allowed.
      banned_addresses:
        # Exact emails that are banned
        literals: ["[email protected]", "[email protected]"]
        # Emails that contains those substrings are banned
        substrings: ["evil"]
        # Regular expressions that match banned emails
        regexes: ["@evil\\.corp$"]
        # Suffixes that match banned emails
        suffixes: ["@evil.corp"]
        # Prefixes that match banned emails
        prefixes: ["alice@"]

    requester:
      # List of IP addresses and CIDRs that are not allowed to register
      banned_ips:
        - 192.168.0.1
        - 192.168.1.0/24
        - fe80::/64

      # User agent patterns that are not allowed to register
      banned_user_agents:
        literals: ["Pretend this is Real;"]
        substrings: ["Chrome"]
        regexes: ["Chrome 1.*;"]
        prefixes: ["Mozilla/"]
        suffixes: ["Safari/605.1.15"]

Note that the previous data.allowed_domains / data.banned_domains still work, but we don't document it anymore

cc @turt2live

Related to #3993
Fixes #1870

Copy link

cloudflare-workers-and-pages bot commented Feb 17, 2025

Deploying matrix-authentication-service-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 7c09b45
Status: ✅  Deploy successful!
Preview URL: https://22eeaabe.matrix-authentication-service-docs.pages.dev
Branch Preview URL: https://quenting-policies-ip-user-ag.matrix-authentication-service-docs.pages.dev

View logs

@sandhose sandhose added A-Policy Related the policy engine T-Enhancement New feature of request labels Feb 17, 2025
@sandhose sandhose merged commit 88f6171 into main Feb 18, 2025
30 checks passed
@sandhose sandhose deleted the quenting/policies/ip-user-agent branch February 18, 2025 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Policy Related the policy engine T-Enhancement New feature of request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expand allowed_domains policy to support email regexes

1 participant