When wyUpdate self-updates it checks google.com then wyday.com. Double click the client.wyc file to see all the sites wyUpdate will contact. You can change these, of course, see: How to make a custom version of wyUpdate.
URL Prerequisites to wyUpdate.exe
Dear Support (e.g. Wyatt or Sam),
We work within several closed and heavily restricted network scenarios where reaching our cloud server for updates could be a challenge. I wanted to get a feel from you how others have accomplished this and what urls must we plan for when asking for limited internet access.
Right now, we planned for the urls that we setup (ftp currently), but while installing on our first heavily restricted access site we ran into a situation where the wyUpdate application errored. The IT department monitored the traffic and identify that the wyUpdate application was attempting to reach www.wyday.com. As soon as they added a rule to allow access to this site the wyUpdate application was able to move forward without errors. Is there a way a way to bypass this check or simply turn it off from the wyBuild level? We may not be able to get www.wyday.com approved for every site.
Please advise. Thank you,
Jim
Thank you for the feedback.
I did look into the client.wyc file and it's encrypted so I'm not getting much value there (I also would prefer it to keep it this way while in production). I'm not the best at C# currently to be gutting code. The reason why I appreciated your product was the easy of use for someone who was not a developer or at least needed to make simple calls to an outside process. Right now, it appears that our customers that need updates within closed networks will not be able to use your product out of the box because of these update checks (Something I should have tested first 😢) and those with very restricted networks will need to open up their firewalls to those 2 urls.
This just complicated things, but thank you for laying it all out on the table.
Jim
We include a client.wyc reader with wyBuild. So if you double click the client.wyc file you'll see what sites it will use.
Right now, it appears that our customers that need updates within closed networks will not be able to use your product out of the box because of these update checks (Something I should have tested first ) and those with very restricted networks will need to open up their firewalls to those 2 urls.
Well, on your next update you can include a new client.wyc that references your own site. But yes, your customers on limited networks with your software already installed will have to add wyday.com to the whitelist (or google.com).
Thank you for the feedback and I look forward to that next update. We don't have a ton of customers that are currently within closed networks, but we do anticipate that list to grow.
In regards to closed networks here is what I had in mind - Standup IIS or something similar, provide them with an ftp account to download the build files to a directory within their web server, then I could have wyUpdate point to their internal server (Something we would pre-configure for their site).
Other than the fact that we would need to recompile the wyUpdate app do you see any other concerns with doing this? How have other customers worked through this challenge?
Jim
Other than the fact that we would need to recompile the wyUpdate app do you see any other concerns with doing this?
Well, if you're hosting wyUpdate on your own sites then you don't need to recompile wyUpdate. Just use our version and host it on your website.
By "your own sites", are you referring to our customer's sites, correct?
Jim
Right.
Ah... Let me clarify, we have a cloud server where we post our update media for our customers. They download it centrally from here to apply to their environments. This server is not located on our customer networks which is why we run into these conflicts. They don't allow the additional sites that wyUpdate requires to check for updating itself.
OK, if you host wyUpdate on your own site (or sites), you don't need to compile your on version of wyUpdate. Just use our version hosted on your site(s).