After I launch Rhino and sign into Cloud Zoo via SSO (Microsoft AAD), I get an error from the brower saying it can’t reach the page 127.0.0.1:1717/?code=eyJhbGciOiJIUz… (long opaque code)
On top of that view I get a “Licensing: Ready to Assign” message (which is odd, but a different topic).
Rhino seems to exit, and on started it again I find that I am signed in and Rhino works just fine. But this is a terrible user experience that I don’t want my non-technical co-workers to have to deal with.
This behavior has been more or less consistent since I moved my company’s licenses from a local server to Cloud Zoo a couple of months ago. It appears that Rhino opens a local web service and listens on it, then stops listening just before the web login process tries to access the above-reference resource.
I’ve opened a case (the communications don’t include a case number), but after a single response, the rep has ignored me.
Before I give up on Cloud Zoo and go back to a locally-hosted license server, has anyone seen this before? Any tips on resolving it?
Hi Craig, I apologise that you didn’t receive the level of support from me that you should have. Our issue tracker is down right now, but I will create an issue for this problem so that we can track it.
We use a local web server for the OAuth2 flow. Rhino does appear, in this case, to be closing the local web server prematurely, though the login is successful. The main problem I ran into during initial investigation is that I can’t reproduce the behaviour. This makes it difficult to figure out the root cause and come up with a solution.
Can you please enable debug logging (see required registry values below) and go through the steps to login to Rhino. Then send over the RhinoDebugMessages.txt file in My Documents. Hopefully this will tell us why the local web server is closing early. If not, we’ll try something else.
I enabled debugging and captured the attached logs.
1 is a normal Rhino startup with a prompt for a license. You can see that Rhino suddenly terminates.
2 is the next startup. I am signed in at this point, so Rhino starts up normally and closes successfully.
3 is Rhino Safe Mode startup with a prompt for a license. Interestingly, Rhino did not terminate early, though I still got the 127.0.0.1:1717 connection refused error.
4 is a repeat of 1, with the AVAIL add-in removed. That seems to have resolved the issue with Rhino terminating early, but again the connection refused error remains.
Thanks for generating those logs. Unfortunately there isn’t anything in there that would point to what’s causing the connection error during login. Running Rhino in safe mode, as you have done, should rule out any interference from plug-ins.
We may need to schedule a remote debugging session to diagnose this further.
This issue appears to be caused by Sophos Intercept-X, specifically “Network Threat Protection”.
My best guess is that Sophos sees the local web server as a Command and Control server. I tried adding the Rhino process to Sophos’ global exception list, but that didn’t help.
I will open a case with Sophos, but I’m open to suggestions.
I was able to resolve the problem by adding “127.0.0.1” as a website exception in Sophos’ Global Exceptions.
The Sophos support rep I worked with suggested that the local web server might be crashing when Sophos probed it.
This is not a great long-term solution, since I can imagine threats exposing themselves as local web services. The whole Cloud Zoo sign-on experience isn’t particularly good - it’s overly complex and unintuitive. Hopefully McNeel will streamline the process in a future version of Rhino.
