Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow image optimization on wildcard hostnames #18632

Closed
lachlanjc opened this issue Nov 1, 2020 · 5 comments · Fixed by #36245
Closed

Allow image optimization on wildcard hostnames #18632

lachlanjc opened this issue Nov 1, 2020 · 5 comments · Fixed by #36245
Milestone

Comments

@lachlanjc
Copy link
Contributor

On https://workshops.hackclub.com, to prevent ballooning the already-multiple-GBs source repo, we have folks upload images/media to the Vercel CDN as individual deployments (using some internal tooling) so the dev experience is faster. However, this means each image is at a different hostname. I’d love to switch our homepage there to use Next.js Image Optimization, but since each image is on a different/unknown domain, we can’t. Two solutions jump out to me:

  1. Disable the domains restriction entirely (opening your site up to being used as an external service)
  2. Allow wildcards or regex in the domains (for us, cloud-*.vercel.app would work fine)—a little more technically/usage complex but is definitely safer
@timneutkens
Copy link
Member

We can’t let people disable it as it would allow you to get 3 types of attack vectors:
• cpu resources being taken for other sites
• Cache overload (the cache growing infinitely when self-hosting)
• Social engineering (people could share images on your domain that could ask people to do a certain thing)

We can consider wildcard support though 👍

@lachlanjc lachlanjc changed the title Allow image optimization on wildcard or non-preset hostnames Allow image optimization on wildcard hostnames Nov 1, 2020
@Timer Timer added this to the 10.x.x milestone Nov 1, 2020
@maximousblk
Copy link

maximousblk commented Nov 2, 2020

Consider this case:

I have an application that fetches and renders markdown content at runtime from external sources (say, GitHub READMEs). In such case, I want to optimise the images referenced in the markdown.

So I'd like to propose the following:

either:

fallback to the basic HTML <img /> tag for domains that aren't allowed by setting fallback: true in the config. This way we can allow common hosting platforms which will be optimised and the renderer will still use the <Image /> component but not optimise the sources that aren't allowed.

module.exports = {
  images: {
    domains: ['domain1.com', 'domain2.com'],
    fallback: true,
  },
}

OR: allow users to explicitly opt-in to allowing all domains by setting something like dangerouslyAllowAllDomains: true in the config. (similar to allowDangerousHtml)

module.exports = {
  images: {
    domains: [],
    dangerouslyAllowAllDomains: true,
  },
}

but this doesn't seem to be the the plan.

@lachlanjc
Copy link
Contributor Author

Both sound great. It’d be really great to have frontend/CSS consistency regardless of the image host, so the fallback option would work really well for that

@mohux
Copy link

mohux commented Nov 9, 2020

yep, facing same problem since we are using S3 which has variant of domains , wildcards would be awesome idea

@tan-ahmed

This comment has been minimized.

@vercel vercel locked and limited conversation to collaborators Apr 21, 2021
kodiakhq bot pushed a commit that referenced this issue May 5, 2022
…#36245)

## Description 
This PR implements a new configuration object in `next.config.js` called `experimental.images.remotePatterns`.

This will eventually deprecate `images.domains` because it covers the same use cases and more by allowing wildcard pattern matching on `hostname` and `pathname` and also allows restricting `protocol` and `port`.

## Feature

- [x] Implements an existing feature request.
- [x] Related issues linked
- [x] Unit tests added
- [x] Integration tests added
- [x] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`

## Related 

- Fixes #27925 
- Closes #18429 
- Closes #18632
- Closes #18730
- Closes #27345

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants