iglu-central
iglu-central copied to clipboard
snowplow
TLS support for iglucentral.com
Hi @premjg - no plans currently. All the schemas are publically available, so there isn't a particular sensitivity.
If your organization won't allow any unencrypted traffic, then it's straightforward to host your own local copy of Iglu Central.
Thanks @alexanderdean for clarifying.
My requirements were rather unusual.
I created an Iglu json schema validator that runs entirely in the browser (accessible at http://jsonschema.help) and would have loved to host it over https.
Of course, because of the same origin browser restrictions, my app cannot make requests to iglucentral.com.
All sorted now; decided to leave it as an http site for now.
@alexanderdean just wondering if there's any update on this? As a friendly reminder TLS provides more than just making traffic private -- it also helps ensure the authenticity of the data, which is pretty important for things like schema/package registries even when the individual items can be uploaded by third parties.
Hi @PeterJCLaw - appreciate the note. I am looping in @jpiekos and @jbeemster who have a better handle on this
Hey @alexanderdean thanks for the nudge on this - there are quite a few considerations for this kind of move to ensure nothing breaks inadvertently with a change in the hosting layer so is something we need to do very carefully.
We also need to make decisions about forcing redirects to HTTPS given all of our direct http refs in every schema: "$schema": "http://iglucentral.com/schemas/com.snowplowanalytics.self-desc/schema/jsonschema/1-0-0#"
Will have a think about how we can start this transition though and get at least a HTTPS option available!
Updating that we have now got a next version of this stood-up with TLS and will be running every test imaginable at this before enabling TLS on iglucentral.com but it is moving again.
@jbeemster thanks for the update. Just wondering how this is progressing? I appreciate that getting to enabling HSTS (while the ideal state) would require a lot of checking to avoid breaking things, but one would hope that just allowing HTTPS alongside legacy HTTP is simpler.
Hey @PeterJCLaw it is progressing albeit a bit slowly at the moment! The risk we are trying to mitigate here is that we are moving from essentially an S3 bucket to a CDN fronted download flow so we need to validate that every interaction that works currently with the existing setup will continue to work with the CDN HTTPS solution instead.
https://next.iglucentral.com is live already and is what we will be using to validate but its not yet reached the top of our backlog. As soon as we are ready to flick the switch I will be updating this thread!
Just updating that at long last we have switched on the CDN in front of Iglu Central and it now supports https!
Details here: https://support.snowplow.io/hc/en-us/articles/24812696604317-Enabling-HTTPS-for-iglucentral-com
Closing as completed - we will be deprecating http entirely in a years time as well as improving other security areas but we do now support TLS.
Thanks, this is great to see.
Regarding the comment in the support article about the value in the schema files:
IMPORTANT: Please note that the URL of the metaschema ("$schema": "http://iglucentral...) should not be changed in your schemas. This is a hardcoded value, and using https in it is not supported. In any case, this particular URL is never actually resolved by Iglu clients, so our plan to disable HTTP has no impact on it.
Is this limitation something for during the transition or do you expect it to be permanent? Asking as while the Iglu clients may not use it, I expect that other tools (such as VSCode when editing the schema) will do so. If it's possible to migrate that url to HTTPS in time that would seem preferable.
That is our plan indeed to add that in but it will take time to update all the different apps that reference meta schema uri - when it's safe to have either we will update the community.