https://webb.spiderden.org/2023/05/26/pleroma-mitigation/
@w Nice guide!
I only have one question: why reconfigure Pleroma to use the subdomain for uploads if I set up a redirect anyway? When permanent fix arrives I can just get rid of the subdomain, but if I reconfigure Pleroma, URLs in new posts would have the subdomain in them so I would have to keep it up (and its cert) forever so the links to images don't become broken.
@w No, I get it, but if redirect fixes it for old posts, why won't it do the trick for new ones? Why is it necessary for newer post to contain direct links to https://media.my.domain, not the usual https://my.domain/media, that get redirected to https://media.my.domain?
Is it assumed that older posts don't contain the malicious script, but newer ones might? Is redirect treated differently from XSS perspective?
@w I see, makes sense. But if it's a temporary fix, slight performance hit isn't that bad. I still hope that a more permanent fix arrives soon 😅
Hosting media on a separate domain might still make sense, but having that extra cert to worry about bugs me.
@w
BTW is there a reason behind media files being served by Pleroma itself, not handled statically by nginx. In my (most simple) configuration uploads are just a directory on the same host, I can just point nginx there to serve them. Are there other reasons it's done that way which I just don't see, besides other uploaders existing and media being hosted in the cloud in more complex configurations ?
@thatguyoverthere Oh, yes, makes sense. It's not like that in my configuration, I just copied the link to an image and retrieved it with curl that doesn't have any session cookies, it worked. But you're right, in more complex configurations there might be some access control involved.
@w
@w Ugh! Link parser ate the https://, but I think you get the idea 😅