Update docs for DDEV usage

[mandrasch]

Description

• add info about web_extra_exposed_ports (https://ddev.readthedocs.io/en/stable/users/extend/customization-extendibility/#exposing-extra-ports-via-ddev-router)
• add origin to vite.config.js and set it to DDEV primary url
• add info about changed manifest path in Vite >= v5

Related issues

Thanks very much for providing this as Open Source!

[mandrasch]

I'll add

export default defineConfig({
  server: {
    // ...
    // Configure CORS for the dev server (security)
    cors: { origin: process.env.DDEV_PRIMARY_URL }, 
  },
})

to this PR. (Discussion: https://discord.com/channels/456442477667418113/456442867163070466/1336287957031718932)

Related security advisory: GHSA-vg6x-rcgg-rjx6

[mandrasch]

Updated the PR, a demo repo for this config can be found here as well: https://github.com/mandrasch/ddev-craftcms-vite/blob/main/vite.config.js

Ready for review ✅

[MoritzLost]

@mandrasch Worth noting that process.env.DDEV_PRIMARY_URL will not work in a multisite project where different sites use different domains. For example, a Craft install that powers client-brand-one.com and client-brand-two.com. In local dev, we use client-brand-one.ddev.site and client-brand-two.ddev.site for those multisite setups (additional domains are added through the additional_hostnames ddev config). In those cases, assets won't load from the secondary domain, because they're blocked by CORS. So a regex that matches against localhost and local testing TLDs is the more general solution, might be better to suggest that in the documentation.

[mandrasch]

@MoritzLost Thanks, very good point!

I though about including it, but I doesn't have it included in https://ddev.com/blog/working-with-vite-in-ddev/ for simplicity. But this could/should be added there as well. But I wasn't sure how many users really use additional hostnames in DDEV.

Do you know by chance what the implications for config/vite.php are in this case for craft-vite? Are changes needed here as well to support multiple local hostnames - or is the Vite devserver just always running/contacted on the primary URL?

[mandrasch]

@MoritzLost Second question

So a regex that matches against localhost and local testing TLDs is the more general solution, might be better to suggest that in the documentation.

What's your current favorite regex solution? Happy to include here in the PR.

[MoritzLost]

I though about including it, but I doesn't have it included in https://ddev.com/blog/working-with-vite-in-ddev/ for simplicity. But this could/should be added there as well. But I wasn't sure how many users really use additional hostnames in DDEV.

@mandrasch Probably not too many projects. Though all multi-sites where the sites use more than one domain require additional hostnames to test them in dev. We have a built a couple of sites like this. Not super uncommon for clients to want to maintain multiple brand or company sites, or multiple smaller project websites from one CMS installation.

Do you know by chance what the implications for config/vite.php are in this case for craft-vite? Are changes needed here as well to support multiple local hostnames - or is the Vite devserver just always running/contacted on the primary URL?

You could always use the URL of the current site I suppose, though we just always use the primary site to load the dev server:

// @var string The public URL to the dev server (what appears in `<script src="">` tags
'devServerPublic' => App::env('PRIMARY_SITE_URL') . ':5173',

This will mean all sites will load assets from the devserver via the primary URL, but I haven't encountered any practical downside to this. Except now for the CORS issue, which can be alleviated with the regex setting.

For the public server, we use a root-relative path, to ensure that assets are loaded from the current URL when testing a real build and when running on production:

// @var string The public URL to use when not using the dev server
'serverPublic' => '/dist/',

That's because we don't want secondary-website.com to load assets from primary-website.com (this would also be a CORS issue again). And I prefer this anyway over full URLs, saves on unnecessary bytes.

The internal dev server URL uses localhost inside the container, anyway:

'devServerInternal' => 'http://localhost:5173/',

That's all I think, ping me on Discord if you want more details on this setup :)

What's your current favorite regex solution? Happy to include here in the PR.

Right now I use the regex that @khalwat dropped on Discord:

cors: {
    origin: /https?:\/\/([A-Za-z0-9\-\.]+)?(localhost|\.local|\.test|\.site)(?::\d+)?$/,
},

Might be slightly overkill, just the part that tests the TLD would probably be sufficient. Now that I think about it, I don't think you need the check for the port number at the end unless you run your local dev domains on a non-standard port.

[mandrasch]

@MoritzLost Thanks very much for the detailed answer, much appreciated!

I don't think you need the check for the port number at the end unless you run your local dev domains on a non-standard port.

jfyi, DDEV introduced Auto Port Assignment when the standard ports are already in use, therefore a port number could be there for some users.

I just checked with https://regex101.com/ ✅

For general DDEV usage, I'd propose

https?:\/\/([A-Za-z0-9\-\.]+)?(localhost|\.site)(?::\d+)?$

I'll update this PR with the general regex, more broader regex though since this is already mentioned in the docs

[mandrasch]

Ready for review! ✅

[khalwat]

Ah this is beautiful, thank you gentlemen.

[khalwat]

New DDEV docs are live now for all 3 Craft versions of the plugin

[mandrasch]

Thanks for merging! 🥳 🎉

JFYI, vitejs core team member reviewed our changes and said it's better to use explicitly (\.ddev\.site) since .site is an official tld and can also be used by attackers.

         origin: /https?:\/\/([A-Za-z0-9\-\.]+)?(\.ddev\.site)(?::\d+)?$/,

Comment by saphire-red ddev/ddev.com#313 (review)

As soon as the Vite article PR is out, I'll add another quick PR here for the docs.

[khalwat]

Good idea on the TLD -- though I will say I think we're getting pretty obscure here, and the actual damage/impact of someone using this exploit is limited.