user_directory_search redirect not working anymore #2954
Comments
|
I can see that the override for the user_directory correctly ist correctly set inside the the search backend client is handling both r0 or v3 |
|
Slavi suggested changing the location to |
|
I dug a little deeper with DEBUG log level and testing by making a search query; when prompting a search with element - add person and type "test") I can see it makes its way through as well as I can also see the search query made in I can also see it in the It seems to me, that it falls back to the default search (which never worked properly with a more complicated search anyway) and and ignores the directory_search redirect to our search backend completely. |
|
Hi. I can see this as well, probably from a different angle, or you can say: different problem: I am using ma1sd service provider, and it seems the new Matrix Spec https://spec.matrix.org/latest/client-server-api/#user-directory Since r0 and v3 seem to be identical, I used a workaround to rewrite v3 -> r0. This makes my service provider ma1sd work again. |
|
Hi, My setup is "older":
Since the newer clients all use "v3" and ma1sd does not understand it, my last post was a workaround to make it work again. Now that you catch What would be the thing to do?
here my config up until now: |
|
I am using ma1sd (for identity and login stuff) as well as maiden (just for a nicer search) but I cant seem to get the redirection working. Now it seems that the redirect variable edit/update: I tried hardcoding my maiden/search-IP, so my effective However, the search still does not redirect it to maiden, since the search just defaults to the faulty ma1sd/synapse search. Maybe I am looking in the wrong place? |
|
@jolly-jump: I think you just need to delete the rewrite part and write the regex for the you probably dont need the extra |
|
@janonym1 : Thanks for the input.
@jolly-jump <https://github.com/jolly-jump>: I think you just need to
delete the rewrite part and write the regex for the |location ~
/_matrix/client/[0-9a-z]+/user_directory/search|. At least on my system,
it always redirects to the default user directory search, which is
|matrix-ma1sd:8090| and should work for you
That is, what I did in first place before figuring out how to rewrite
the "v3" into an "r0" and how to make it permanent.
The problem is: the user directory search does not work then. There is
no message whatsoever from the ma1sd service, I am already using the
debug-mode.
My research into the source code showed me the hardcoded "r0" in the
Java-code of ma1sd (and no v3) so my assumption is that ma1sd in the
most recent version (2 year old v2.5.0)
https://github.com/ma1uta/ma1sd/blob/master/src/main/java/io/kamax/mxisd/http/undertow/handler/directory/v1/UserDirectorySearchHandler.java
does not understand any newer Matrix spec, thus no "v3" and thus no
wonder that directory search does not work.
Anyway, I would be surprised if user_directory search would work for you
with a recent element-web/desktop and ma1sd as user_directory backend.
|
|
You could be right, its possible that my synapse-homserver or synapseSQL itself does the search (instead of redirecting to ma1sd). I get search results even without my backend working, so I need to check if the redirect even reaches ma1sd and is involved or the synapse-default search (or some default) takes over |
|
Okay, I am not now sure, how and why my redirect ever worked in the first place :D I played around with your workaround and suggestions, so my effective config looks like: Note: and now my backend maiden search (or ma1sd for that regard with: I assume, something with the v3 synapse directory search and its API handling changed over last months since my simple redirect worked fine by then (Back then, I just went with |
|
Maybe we should enable just |
Yes, that is what I stumbled upon as well... and now that you mention it again: The reason is the modifier your last comment "use just a hint, seemingly unrelated: |
…x/client/r0) Hopefully fixes: #2954 Untested. Patch inspired by: #2954 (comment)
|
In ad23055, I've made some changes inspired by this comment by jolly-jump. Hopefully this fixes the issues. Feel free to experiment further and submit a proper (tested) PR though. |
|
Thanks for the quick reaction. |
|
Ok. I dug a little deeper for my sanity. I guess, ma1sd is coming to its end, if there is no own updating it to the recent matrix spec. |
|
Thanks for the historical recap! Interestingly, I've never heard of maiden. ma1sd is dead. It can be forked and it shouldn't be too hard to add the v3 URL endpoints (and point them to the same code paths that handle r0 now), or to rename r0 to v3. Of course, someone needs to have interest in maintaining this fork. The playbook would gladly switch (once again) to something that works. |
* Update matrix-domain.conf.j2 exchanged "^~" with "~" as a pattern matching in the location part. I am very sure, that it only works using "~". I am not quite sure though, if this is the right way to do it, because "~" is probably more expensive than "^~" the rewrite has to be behind the definition of the $backend. Otherwise nginx will fail to work. This is probably because "break" goes directly to the proxy_pass which uses $backend. * Update matrix-domain.conf.j2 also change the order of "set $backend" and "rewrite" here in the 3pid registration section * Update matrix-domain.conf.j2 - repeat v3_to_r0 rewrite in else-statement as you said: repeat it for the else-case, where the ma1sd might be running on sans_container. * Update matrix-domain.conf.j2 - corrected wrong variable atrix_nginx_proxy_proxy_matrix_3pid_registration_v3_to_r0_redirect_enabled is the right variable to check (twice) in the corresponding branch. * matrix-domain.conf.j2 - fix-2954: change all whitespaces to tabs as you do it --------- Co-authored-by: Tobias Küchel <t.kuechel@humboldt-ka.de>
…x/client/r0) Hopefully fixes: spantaleev#2954 Untested. Patch inspired by: spantaleev#2954 (comment)
…pantaleev#2985) * Update matrix-domain.conf.j2 exchanged "^~" with "~" as a pattern matching in the location part. I am very sure, that it only works using "~". I am not quite sure though, if this is the right way to do it, because "~" is probably more expensive than "^~" the rewrite has to be behind the definition of the $backend. Otherwise nginx will fail to work. This is probably because "break" goes directly to the proxy_pass which uses $backend. * Update matrix-domain.conf.j2 also change the order of "set $backend" and "rewrite" here in the 3pid registration section * Update matrix-domain.conf.j2 - repeat v3_to_r0 rewrite in else-statement as you said: repeat it for the else-case, where the ma1sd might be running on sans_container. * Update matrix-domain.conf.j2 - corrected wrong variable atrix_nginx_proxy_proxy_matrix_3pid_registration_v3_to_r0_redirect_enabled is the right variable to check (twice) in the corresponding branch. * matrix-domain.conf.j2 - fix-2954: change all whitespaces to tabs as you do it --------- Co-authored-by: Tobias Küchel <t.kuechel@humboldt-ka.de>
…x/client/r0) Hopefully fixes: spantaleev#2954 Untested. Patch inspired by: spantaleev#2954 (comment)
…pantaleev#2985) * Update matrix-domain.conf.j2 exchanged "^~" with "~" as a pattern matching in the location part. I am very sure, that it only works using "~". I am not quite sure though, if this is the right way to do it, because "~" is probably more expensive than "^~" the rewrite has to be behind the definition of the $backend. Otherwise nginx will fail to work. This is probably because "break" goes directly to the proxy_pass which uses $backend. * Update matrix-domain.conf.j2 also change the order of "set $backend" and "rewrite" here in the 3pid registration section * Update matrix-domain.conf.j2 - repeat v3_to_r0 rewrite in else-statement as you said: repeat it for the else-case, where the ma1sd might be running on sans_container. * Update matrix-domain.conf.j2 - corrected wrong variable atrix_nginx_proxy_proxy_matrix_3pid_registration_v3_to_r0_redirect_enabled is the right variable to check (twice) in the corresponding branch. * matrix-domain.conf.j2 - fix-2954: change all whitespaces to tabs as you do it --------- Co-authored-by: Tobias Küchel <t.kuechel@humboldt-ka.de>
Describe the bug
Hi!
We have
matrix_nginx_proxy_proxy_matrix_user_directory_search_enabled: trueset because we have to run our own search service (since we have a complicated LDAP environment), which runs as a service in the background and accepts search requests at port 8088. The search backend service runs fine and I can call the search API over curl as always.However, it seems that the routing/redirecting of the API with
/_matrix/client/r0/user_directory/searchis not working anymore. I am not sure when exactly this happened but it must have been in the last few months tops as it worked with the same config before that.To Reproduce
My related config in the
vars.ymlfile looks like this:Note: we needed
client_api_host_bind_portfor our search workflowPreviously this worked fine but with the latest updates, this redirection to our search service broke somehow. I assume it has to do with the ongoing migration over to traefik and away from nginx but I am not sure, where exactly I should try define the new redirection.
We are using traefik
matrix_playbook_reverse_proxy_type: playbook-managed-traefikbut there are still some services running using the nginx proxy (e.g. oidc, basic auth, metrics..)Looking at the server, we have the
matrix-nginx-proxy.service,matrix-traefik.serviceas well as our worker nodes running throughmatrix_synapse_workers_enabled: true. I assume with time, most (if not all) services and proxies will be completely migrated to traefik and I am not sure, if thematrix_nginx_proxy_proxy_matrix_user_directory_search_addr_sans_containeris still working. I assumed so, since thematrix-nginx-proxyalso still exists.Do I have to write some rules for traefik or does this sill get handled by the (for now still existing) nginx-proxy?
Expected behavior
The search flow
/_matrix/client/r0/user_directory/searchis redirected to our search backendMatrix Server:
The text was updated successfully, but these errors were encountered: