Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set policy problem #33

Open
DimitryVo opened this issue Dec 2, 2024 · 1 comment
Open

Set policy problem #33

DimitryVo opened this issue Dec 2, 2024 · 1 comment

Comments

@DimitryVo
Copy link

DimitryVo commented Dec 2, 2024

Hello, I have checked two matchRules of policy "id": "custom-hook-to-reject-room-creation-once-in-a-while":

  1. "routeMatchesRegex": "^/_matrix/client/r0/createRoom",
  2. "matchRules": [ {"type": "method", "regex": "POST"},
    {"type": "route", "regex": "^/_matrix/client/r0/createRoom"} ]
    First matchRule is worked (block create of room), but second is not.
    Could you recommend anything how to use multi condition match policy (second matchRule).

In additional, can I use policy for restrict user's media by IP mask and userAgent (mobile/PC)?
Thank you.

@spantaleev
Copy link
Member

Are you sure your users are invoking /_matrix/client/r0/createRoom and not something else like /_matrix/client/v3/createRoom?

Perhaps you should use a regex like ^/_matrix/client/[^/]+/createRoom to catch both r0, v3 and other versions that may come in the future.

I'm not aware of /createRoom APIs being exposed over other HTTP methods (methods other than POST), so you can more easily disregard the HTTP method and keep your matchRules simple (just matching the route).


Matching against specific the User-Agent HTTP header (or any other arbitrary HTTP header) is not supported yet. We may add support for it if it's very useful.

Instead of doing that, you could use a consult.RESTServiceURL action and send the request to your own API server for inspection. Over there, you can read the full request details (User-Agent HTTP header, etc.) and decide if the request should be be allowed to pass, be rejected or somehow be modified. Using this action is most flexible (it lets you do anything you wish), but requires that you run an API server somewhere and to suffer the (usually small) overhead of requests leaving matrix-corporal and going to your API server.

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

No branches or pull requests

2 participants