|
| ▲ | mcfedr 4 days ago | parent | next [-] |
| The reason not to do that is that dev.example.com can set cookies on example.com and other envs can see them. |
|
| ▲ | thayne 4 days ago | parent | prev | next [-] |
| That only works if you (and any third party code that might run on such a domain) are completely consistent about always specifying the domain as one of your subdomains whenever you set a cookie. And if your marketing/SEO/business people are ok with having something like "prod" as a subdomain for all your production web pages. |
| |
| ▲ | sensanaty 4 days ago | parent | next [-] | | Usually it's mainsite.com for the marketing site, and then app.mainsite.com for actual production, or if you have multiple it'll have the product name, like coolproduct.mainsite.com We then have app-stg and app-canary subdomains for our test envs which can only be accessed by us (enforced via zero trust). No reason for marketing or SEO teams to care in any case. | |
| ▲ | netdevphoenix 4 days ago | parent | prev [-] | | When was the last time you saw a public website like that? prod.companyname.com websites are extremely rare especially outside tech. | | |
| ▲ | graemep 4 days ago | parent [-] | | The production site could be www. or something else that makes sense. |
|
|
|
| ▲ | jan_g 4 days ago | parent | prev | next [-] |
| We have *.example.dev, *.example.qa, *.example.com for development, staging/qa and production. Works well and we haven't had any issues with cookies. |
| |
| ▲ | teaearlgraycold 4 days ago | parent [-] | | This works fine and is what I’ve done. But if you’re sending email from those domains or working with enterprise customers using the same TLD will be helpful. |
|
|
| ▲ | teaearlgraycold 4 days ago | parent | prev [-] |
| Ah yes if you use a CNAME that would work. You know better than me. |
