-
-
Notifications
You must be signed in to change notification settings - Fork 884
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
Rewrite images to use local proxy #4035
Conversation
def4f2d
to
44d8168
Compare
crates/routes/src/image_proxy.rs
Outdated
url: String, | ||
} | ||
|
||
async fn image_proxy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@asonix would using the lemmy-backend to proxy picture requests be a better approach, or maybe waiting for pictrs v.50 which has picture proxying, and using those pictrs routes? Any pros/cons to either?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proxying images through lemmy is fine, but it means the original server must be online and capable of serving the image for each request. using pict-rs' proxy method in 0.5 will cache the proxied image and reduce load on the original server
I think doing this initial proxy work now probably makes sense, and using pict-rs' proxying in the future can be made a lower priority (and give more time to folks to upgrade to 0.5 when it releases before you start depending on 0.5 endpoints)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case @Nutomic just add a TODO somewhere that we can remove this once pictrs 0.5
is released.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, adding comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed it to use pictrs for proxying. Also added a config option for image proxy which is disabled by default, with comment noting that pictrs 0.5 is required.
One other concern I have that makes me think image proxying should probably be done in front ends: cross-posting. If a link URL points to an image on IE so maybe instead of actually rewriting links, we just provide the |
@dessalines If multiple posts have the same url, those will all be rewritten to the identical image_proxy url so crossposts will still work. If this logic is handled in the frontend then each one will have to reimplement the same logic, doesnt make sense. |
77d0af5
to
7306153
Compare
crates/utils/src/settings/structs.rs
Outdated
@@ -65,7 +65,15 @@ pub struct PictrsConfig { | |||
|
|||
/// Cache remote images | |||
#[default(true)] | |||
pub cache_remote_images: bool, | |||
pub cache_remote_thumbnails: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This setting might be unnecessary now. However the file request.rs where its used is quite the mess, not sure when I can get around to cleaning it up (it needs almost a complete rewrite).
Ready to review now. Edit: Did some testing using local docker setup and its working as expected |
crates/api_common/src/request.rs
Outdated
|
||
if !pictrs_config.cache_external_link_previews { | ||
return Ok( | ||
proxy_image_link( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block here is confusing now. Maybe we should remove cache_external_link_previews
entirely now, and just leave image_proxy
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cache_external_link_previews
and image_proxy
seem like two bools that refer to the same thing now then.
I'm tracing down every usage of RemoteImage::create
, and sometimes it uses the first setting, sometimes the 2nd. We should simplify and get rid of one of them.
@dessalines The But it doesn't refer to the same thing, its purpose is to specify wether you want to store thumbnails locally (in pict-rs), or just hotlink to external images. And the In my case I dont want the images to be proxied and I also dont want to store them locally. So a single setting would not be enough. |
@kroese @Nutomic in that case they seem exclusive then, and we have 3 options, and should use an enum rather than 2 bools:
Some names could be |
Yes they are exclusive, because the value of Also in the current release there is a bug that |
* Extracting opengraph_data to its own type. * A few additions for markdown-link-rule. --------- Co-authored-by: Nutomic <me@nutomic.com>
Makes sense, Ive converted it to an enum now. You can see it in config/defaults.hjson. For now Im keeping the existing behaviour as default to avoid breaking changes in a minor version. But if the proxying works well might be able to remove |
I still think the naming is not as clear as it could be. The setting is called If it was my decision I would just call the setting |
The new image proxying from this PR applies to all images, including avatars, markdown embedded images etc. However the old storing of preview images only applies to post urls. So I think the naming makes sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! BTW pictrs v0.5.0 is released now.
Did you want this to go in the upcoming release, or leave it for later? My main concern is I want our release notes to give full instructions on how to upgrade pictrs.
Should be fine to include it as it doesnt change the main behaviour unless you add the config option. For pictrs we can simply link to the readme. |
Added |
c1323e5
to
2fd7edd
Compare
LGTM, but lets have @phiresky take a look before merging. And when you can, please add some detailed instructions for LemmyNet/lemmy-ansible#213 , because I'm sure this will cause some issues unless people know the proper way to upgrade pictrs seamlessly. |
I decided to play around with markdown handling to see how we can rewrite image and link urls. Turns out its pretty simple. So far it does this:
rel=nofollow
to all links to discourage spammers. Note that this wont affect lemmy-ui or other frontends as they do their own markdown rendering. It will only affect emails, RSS feeds and different federated platforms.https://lemmy-alpha/api/v3/image_proxy?url={url}
so that users dont connect directly to remote servers.This PR doesnt have any breaking changes so it can be merged whenever.
Todo:
markdown_rewrite_image_links()
on all markdown before writing to db (api and apub)rel=nofollow
cache_remote_thumbnails
todisable_external_link_previews
Image
based on mime type for better compatibilityAdd a cache for proxied images with configurable size, stored on disk (or rather leave this to nginx?)-> leave to pictrs