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? 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

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