Staging-domains & License key & Control panel access

[jannisborgers]

I’ve built a lot of CraftCMS websites over the last years, but it’s only when new projects arrive, which were set up differently, that I realize I’m not sure I understand all the intricacies of the licensing model correctly and want to make sure I’m doing everything in a legal way.

First of all: All of the websites mentioned here that are live have a license attached to them via id.craftcms.com and their primary site url is bound to that license.

Staging sites/domains

Most of these websites have staging clones that are not hosted on the client’s IT via a subdomain, but on our own (or our partner’s) webservers, and are password-protected („non-public“). Their domains are always something like clientproject.our-staging-server.com.

We’re seeing warning messages in the staging sites’ control panel that The license in config/license.key belongs to primary-public-domain.com. This is because none of Craft’s non-public domain requirements are met.

I was under the impression that I could ignore these messages, as long as there is a license attached to that staging site’s public sibling. Is that the case, or do we have to change our setup to make sure that our staging sites are hosted on „non-public“ domains? For example, would adding the word „stage“ to their subdomains work? Otherwise we would have to buy a new domain for each staging site and add a stage subdomain to it (I would like to avoid that for obvious reasons).

Restricted control panel access

Unrelated: On multi-site installations, we can log into the control panel by adding /admin to the site URL. In Knowledge Base articles, it is stated that you can only access the control panel on a single public domain. Is this a legal restriction? And if so, can I enforce it via the projects configuration? Because technically, I can visit the control panel from all site URLs inside of an installation.

[janhenckens]

For the first part of your question:
Craft uses these 2 files (1, 2) to check wether or not the site is on a development domain. You can make a pull-request to add your staging domain (if it's a generic url), or switch to one that contains one of the keywords.

We run a similar setup, but everything is under the company domain, not under the client's (eg: project.staging.agency.tld)

[jannisborgers]

Thanks, Jan! So one of the reserved words would have to be a complete subdomain, right? project.stage.agency.tld would work, while project-stage.agency.tld (sic: hyphen) would not work?

And while I knew about the dev domains file, I hadn’t noticed that it only includes the domain, not specific subdomains. I could put our staging domain in there and all sites on subdomains of that domain would be whitelisted? Putting our staging domain on Github publicly always seemed a bit risky, which is why I didn’t consider it…

[angrybrad]

@jannisborgers

So one of the reserved words would have to be a complete subdomain, right?

Nope - we split on the "word boundary" which includes the hyphen, so project-stage.agency.tld should work.

https://github.com/pixelandtonic/craftnet/blob/master/src/cms/CmsLicenseManager.php#L128-L131

I hadn’t noticed that it only includes the domain, not specific subdomains.

All Craft licensing cares about is the root domain (since subdomains are included for "free" on a single Craft installation).

[jannisborgers]

Thank you Brad! I’ll look into these options. So the way I have it currently set up is not okay and could lead to legal consequences, right?

[mightywiley]

Craft uses these 2 files (1, 2) to check wether or not the site is on a development domain.

Is this still an option? If so, where & how? Thanks!

[brandonkelly]

The repo is no longer public, but you can write into support@craftcms.com with your staging domain, and we will consider allowing trials on it. (The domain must be obviously meant for staging purposes only.)