because the http urls won't make sense anymore, as soon as token auth in query strings are removed?

looks like it's working

In reply to@timegrid:matrix.c3s.cc

because the http urls won't make sense anymore, as soon as token auth in query strings are removed?

removal seems to be pending, but i don't know where to look for timelines. the proposed solution in that ticket was what i thought of after looking into the code. i'm just a bit afraid, that the removal will suprize me like the authed content ^^ in any case, thx for the PR

In reply to@timegrid:matrix.c3s.cc

removal seems to be pending, but i don't know where to look for timelines. the proposed solution in that ticket was what i thought of after looking into the code. i'm just a bit afraid, that the removal will suprize me like the authed content ^^ in any case, thx for the PR

nex (she/it): i think there's still a bug in mxc_to_http. im the moment client, when i copy some image url in an unencrypted chat, the homeserver part is missing.
formerly the link was e.g. https://matrix-client.matrix.org/_matrix/media/v3/download/matrix.org/jWejjMToIAwRXmAChJApoyjc
now it's /_matrix/media/v3/download/matrix.org/jWejjMToIAwRXmAChJApoyjc?access_token=[...]
i could look it up, how moment calls nio, but i think it has to be in mxc_to_http

it's due to calling _build_path, this won't prefix the server part

if mcx_to_http is just a helper function to convert matrix content URIs for sharing purposes, one could argue, that it should better not leak the authentication_token at all though. of course clients could use it in a different way

moment for example also uses the function to fetch the url of the avatars, which would break without access_token. probably i'd just remove the image sharing function to prevent its leakage, which will be obsolete anyway then. just as a reminder, that the query parameter issue might be more severe (ppl are used to just copy and paste the url) and clients might need to take action to protect their users

In reply to@timegrid:matrix.c3s.cc

if mcx_to_http is just a helper function to convert matrix content URIs for sharing purposes, one could argue, that it should better not leak the authentication_token at all though. of course clients could use it in a different way

In reply to @nex:nexy7574.co.uk
@Alex Has the use of encrypted_mxc_to_plumb come up in your testing at all? It has just dawned on me that I'm not entirely sure how the access token is meant to be passed to it, since I've never encountered it myself

no, the function is not used anywhere in nio and neither in moment

In reply to @nex:nexy7574.co.uk
as for the token leak - this is the reason it's deprecated. Unfortunately, until #511 gets dealt with, not much can be done about that, and people will just have to exercise caution. Perhaps a warning.warn(UserWarning) or something like that would be appropriate, for the time being?

i know it won't fix soon. in this case, the main problem is, that formerly the media url was meant to be shared. i don't know, but assume that nio is also used for many bots/bridges, which might share the images via the url of mcx_to_http. communication is important at least. a sufficently highlighted entry in the changelog (also that it's breaking media on older servers). some log message might help, too, sure. on the other hand, the nio version might be not controllable by the client devs (system packages) and they might not be aware. to be safe, one could also add a flag for a while to enable the new behaviour, which needs to explicitly switched on, so the responsibilty shifts to the client devs. not sure, if that makes sense though