Use ImageSharp.Web in client websites requesting images (with commands) to another domain (media website)

[utilsites]

I have 2 client websites that need to request images (with commands) from a media website.

I configured ImageSharp.Web on the client websites and also in the media website.
On the client websites, the ImageSharp.Web TagHelpers works well only if I use:
<img src="//mediadomain/image.jpg" imagesharp-width="100" ...> (src URL starting with //, without using http:// or https://).
Because ImageSharp.Web TagHelpers ignore the commands if the domain is different from the current website and the URL has the protocol.

I searched in the issues and found a related post, but the solution is not clear to me, at beginning I was expecting to have the ImageSharpMiddlewareOptions.IgnoreHost configuration, but it seems the implementation went another way related to the cache keys? Not sure if it fits what I need, or it's a different problem, and how to configure ImageSharp.Web, can someone help please?

Note: in dev I also need ports on the url.

[utilsites]

Hi @JimBobSquarePants, can you give some feedback please?

[JimBobSquarePants]

Your requirements are entirely different. I’ll explain why.

That PR (which was superseded by an improved design, read to the bottom) allows the use of host agnostic relative path cache keys. That cache generator is now the default.

You require custom IImageProvider and IImageResolver implementations to allow you to source your images in a single external source. The taghelper correctly does not work with external domains because you cannot intercept requests to external domains, your path must either use a full path to the same application domain or a relative path.

Your custom implementations would make HTTP requests to your media server to return the source media. You can use your own custom relative path that the implementation recognises to allow interception

[utilsites]

Sorry, I don't understand the need for intercept requests to external domains and why there's such a strong restriction on them.
Is it just due to the lack of support for URLs starting with ~/?

The Razor tag <img> supports internal URLs (absolute and relative with optional ~/) and external URLs. Why doesn't the ImageSharp ImageTagHelper behave the same?

The only weakness I see is the HMAC key being unique regardless of the external server, but this isn't a problem for a unique media server.

I noticed the limitation in the http URL prefix validation in the Process() function of ImageTagHelper.cs. It seems it would just require removing this validation. Perhaps could be added a configuration option to enable this validation.

The suggested implementation seems too complex for my knowledge level, and would require forking the project. I understand the project wasn't architected to support a media server, but this is a very useful scenario and likely not unique to me.

If the suggested change can't be done, I think I can manage working with URLs starting with // but it's not ideal scenario and hope it will not break in future releases.

Thank you for the help. I really like this project, it just needs this one point to be 100% perfect. :)

[JimBobSquarePants]

Sorry, I don't understand the need for intercept requests to external domains and why there's such a strong restriction on them.
Is it just due to the lack of support for URLs starting with ~/?

URLs beginning with ~/ are supported just fine. The taghelper resolves them to / just like the standard img taghelper.

The reason ASP.NET Core Middleware cannot intercept requests to external domains is because middleware operates within the web server environment, and its purpose is to handle and process requests that the server itself can manage. When a request is made to an external domain, it bypasses the server's control and goes directly to the external server.

Here's a simple analogy to further clarify things.

Think of your ASP.NET Core application as a well-secured building. The middleware acts like security guards inside this building, ensuring everything runs smoothly and securely. These guards can only monitor and control what happens within the building itself.

When you make a request to an internal URL, it's like moving items within the building—the security guards can oversee and manage this. However, when you make a request to an external domain, it's like sending something out to another building entirely. The security guards in your building can no longer see or control what happens once it leaves their premises.

This is why we explicitly filter external URLs and use the base resolution functionality to render them exactly how a standard img tag would.

I understand the project wasn't architected to support a media server, but this is a very useful scenario and likely not unique to me.

ImageSharp.Web is designed to handle centralized media servers, and the IImageProvider interface is explicitly designed to allow requesting images from any source. This ensures that images can be securely managed and processed within the server environment.

[utilsites]

What I meant to say is that the standard tagHelper for the <img> tag supports both relative and absolute URLs, but it was a poor comparison.

Thank you for the explanation with the analogy.

I tried implementing IImageProvider and IImageResolver using the external website, making HTTP requests in the implementation. In debug mode, it worked well in retrieving the stream and file information, but then I encountered a 404 Not Found error on the browser for the images. I'm not sure if I missed rewriting the URL or if there's another issue. I couldn't find documentation to help, and checking only the source code left me with some doubts.

Would it be possible to add another provider WebHttpImageProvider to ImageSharp.Web to complement the existing AzureBlobStorageImageProvider and AWSS3StorageImageProvider?

I also tried configuring the PhysicalFileSystemProvider with ProviderRootPath of the other site's media (since it's on the same machine), but I couldn't get it to work properly.

I ended up using the solution of prefixing the URL with //, which works well for external URLs with ImageSharp.Web ImageTagHelper processors. I also created another TagHelper to replace the /webmedia/ prefix with an external URL prefixed with //.

This solution doesn't adhere to the mentioned security analogy, but since the <img> tags are controlled by us, and they will have HMAC keys for command security, and the external media site is also controlled by us, I believe there are no security vulnerabilities. Or am I missing something?

Thank you for your help.