Bugs in licence validation

[Terry Ellison]

• The current algos in init.c:licenseKey() and init.c:checkLicenseKey() currently allow sloppy compares of the registered and actual site URLs; effectively ignoring http vs https.  However, http://site/ is a synonym for http://site:80/ and https://site/ is a synonym for http://site:443/ yet if you (sometimes) use the explicit ports, the key checks will fail.
• I picked this up because I need use a non-default https port for my test instance and I was debugging why this was raising a licence error. 
• More annoyingly in this case , the Manage Purchase > Change Licensed URL option does not allow you to change the Test URL to add an explicit port, because: Before you can change the URL, you must first remove the existing installation.   So by this logic I've got bring my production forum down and offline for some unspecified time just to update the port used for my test environment.
  Well some business analyst really thought through the specification of that update function! 😅🤣

Edited October 24, 2021 by Terry Ellison

[Marc]

Sorry to hear you feel the function is not suitable for your needs there, however we did indeed think through the specification of that function, and what you are seeing there is intended. We allow only one live and one test instance of the platform, and would expect that the test instance stays on the same URL. If you find a absolute need to change it of course, let us know and we can assist you without the need of having to take down your licence site.

[Terry Ellison]

@Marc Stridgen, thanks for getting back to me.

Can you please enlighten me as to the business rationale for asking your customers to remove / decommission a production website in order to change the test URL? 

Through your customer support request function, I logged a call to change my test URL from https://xxx/ to https://xxx:4443/ and your agent responded by removing the test URL.  However, I still can't set a new test URL to https://xxx:4443/ without getting stuck on that tedious you must first remove the existing installation  error.

In our case, our Virtual Server hosting our production service also used to host our shared test instance.  However over the years our uploads hierarchy is now so large that we need to migrate to a new larger VS; incidentally our production server can no loner carry two complete instances: prod + test.  Clearly, I still want to do full dress rehearsals before the move; however, because of port forwarding constraints, it was just a lot easier to ask our testers to use https://xxx:4443/, since we only have a few testers.  Simple, I thought.  Surely this a pretty standard usecase?   Nope.

Yes, I agree that it is entirely reasonable that you ask customers to decommission an old test site before doing a change to the test URL, but in my case there hasn't been a test forum offered at the old test URL for over a year.  IMO, the flaw in your CRUD validation is that you don't treat the prod and test URLs as separate entities, but instead blur them into a composite. If the production site URL is unchanged, then surely you shouldn't require that the production site is decommissioned in order to change the test URL: only check the subdomain that is being changed.

Also make sure that your reporter / licence check API treats hostname and hostname:port keys consistently; in other words if you treat xxx:4443 and xxx(:443) as separate installations, then an install on xxx:4443 is not evidence of an install on xxx:443.

Lastly, if your customer asks to change a test URL to XXXX  and your existing maintenance validation rules (invalidly) prevent what is a reasonable request from a business perspective then please don't reset the URL and ask them to try again; just do what they ask. 

[Jim M]

Please ensure that you are using a test key when assigning your test URL in ACP -> System -> License Key. I looked on your license and your Test URL is indeed empty for Test URLs.

We recommend setting your test URL to a sub-domain of your Live URL's domain. That way, it's a simple DNS change to move an instance to a different server and there is no headache about what you're needing to do here.

While we are rather flexible with the Test URL system in terms of requests coming, it is setup to not let the client change it to avoid abuse of our policy. Thus, at current stage, this is not something which could be done and submitting a ticket is the only way to change your Test URL (no matter if your test installation actually exists or not).

[Marc]

Just to clarify here. Its that we do reset the test instance when the live is reset. Its not that we ask people to decommission their live. Its actually more that we ask when a test instance is set for you site, you always use that test location. Many customers will use a subdomain for this purpose that they can point to another location if required, however yours is an odd case whereby you wish to use a port at the end of your URL for some reason. 

The intention of this is to stop abuse of the test system by people who are trying to use these as live licenses. Something we have unfortunately come across in the past. Its certainly not to stop you testing, and if you do for some reason find that you absolutely have to change the test URL, just contact us and we can go through that with you. You don't need to decommission your main site, nor would we ever ask for you to do that.

[Terry Ellison]

20 hours ago, Jim M said:

Please ensure that you are using a test key when assigning your test URL in ACP -> System -> License Key. I looked on your license and your Test URL is indeed empty for Test ... this is not something which could be done and submitting a ticket is the only way to change your Test URL (no matter if your test installation actually exists or not).

My production server has a subdomain forum and my test subdomain test.

I submitted a ticket to change it from https://test.domain/ to https://test.domain:4443/.  Your agent (Marc?) responded by clearing the test URL and suggesting that I do this myself — which I can't. Check the date of the change. 

I really can't understand why you feel that using a non-standard port for test could represent an abuse of the testing facility. Surely if anything switching to non-standard port would surely make such abuse more difficult as end users would be unlikely to use non-standard ports?

@Marc Stridgen, IIRC you have some limitation on up to two test URL changes per year. This is my first such change request in ~5 years, and all I am asking is to add a non-standard port.  In your email response you state:

Quote

So you can now add the test instance in any location you need to, be this the URL mentioned below or another location if you choose to do so. I have to be honest here and say Im not sure what else we could have done for you, as we have indeed done exactly what you needed.

If I click on the Change Licenced URL function to add a test URL as you suggest, I get the error:

Quote

Sorry, there is a problem

There seems to still be an installation of Invision Community at the URL on file. Before you can change the URL, you must first remove the existing installation.

---

• Contact Us

So I am simply asking you to reinstate my test URL but with the non-standard port 4443 as your maintenance function doesn't allow me to do so.  This is compliant with RFC 2818 (see para 2.3).

As I explained, I want to bring my test instance online because we are running out of space on our current production VPS and I want to do a full scale test of the migration. 

The production VPS doesn't have the capacity to run the test instance, so I want to move it to another server where we use the convention of port 4443 for test instances. The alternative is to procure another VPS because Invisioncommunity doesn't seem to support RFC 2818.  If this is a hard constraint then I will have to investigate alternatives. I am just really confused as to why you feel using non-standard port for test instances is such an "odd case", when it is really quite common practice in the industry.

Edited October 26, 2021 by Terry Ellison

[Marc]

There seems to be a significant amount of confusion here. Sorry if you feel we have not been clear here, and let me see if we can get this cleared up.

There has been no stating that these can be changed x times per year. In fact generally, these can only be changed yourself when changing your main license. However as stated in the ticket a few times and on here, we can do this for you. Not only can we do this for you, but it has already been done for you.

The second part of the confusion is what happens. We do not set the licensed test URL. If you wish for me to do so, I can certainly do that, but we would generally 'reset' the test URL. By this, it means it is wiped. Yours is currently reset, so you can use it on the test URL you specified, on that non-standard URL specified. A URL (test or production) is actually set when the license polls the server. So when your system at that 8443 URL polls the server, it will set the test URL on file. 

I am very much confused here as to why you are stating we are not allowing you to change your test instance. Our very first response to you here stated we can certainly do that for you. My first response in your ticket also stated the same (and indeed reset that test URL)

In summary here. You want to set your test URL to a new URL as you are using a different port. Your licensed test URL has therefore been wiped so you can use your test instance on that new URL (the one on 8443) should you wish to do so. 

[Terry Ellison]

@Marc Stridgen, I am referring to the old InvisionPower website notes circa 2016 where you gave Test URL volatility advice. (My possibly flawed memory only; I can't be bothered to start trawling Wayback for exact content).  However, I accept in our fast moving world, statements made 5 years ago are ancient history.

At last the penny drops: how you set the test URL seems to have changed.  Your the Manage Purchase > Change Licensed URL function doesn't allow you to set or modify your test instance.  (I am not sure what it does.)  You implement setting the test URL by the customer doing a clean install or by executing the AdminCP > System > License Key > Change License Key function in the test instance with -TESTINSTALL appended to your already registered key, and this registers your test instance. 

Hey Presto! Thank-you!

Note that you don't actually say this anywhere in your License Keys & URLs documentation. Perhaps you expect customers to work this out by inspiration or divine intervention? 😋  A simple para in plain English in your documentation would really help other customers to avoid this hassle and reduce nugatory support agent time.  How about supplementing the paras "In addition to the main live URL..." with a cross reference to the Install and Upgrade page for more details?  Also it would be really helpful if this Install and Upgrade section could spell out the details a little more explicitly:

• This section should contain an explicit statement on business constraints of use for any shared test instance: access should be limited to testers for the sole purpose of testing, and access control mechanisms should be in place to ensure that the test service is not accessible to public or general community members.
• Localhost test instances are for the sole use of the developer using the workstation.
• As well as developer testing of customised skins and add-ons, the second most common test usecase is where a sysadmin might want to do a full dress rehearsal of a live upgrade for timing and volumetric validation, as well as ensuring the upgrade doesn't screw up and extensions and add-ons.  This latter case can only be meaningfully done on a full clone of live, and hence this will typically not be a fresh install, but more usually a (tweaked) database and filestore deep copy, but with a test license key applied through the ACP > Change License Key function updating the key to a test install (and not the somewhat misnamed Manage Purchase > Change Licensed URL function).
• If the customer needs to change the live or test URLs for valid business reason then this can be discussed by raising a case through the standard Support Request mechanism.  Once the relevant field has been cleared, a new live or test URL can be registered through the ACP > Change License Key function.

[Marc]

Thank you for your feedback. I will pass this on to the team, and glad you got where you need to be