Change API Key after deploying compute

Have you tried restarting your VM? That might help. If you are sending the /activechildren endpoint as a GET action, you don’t need the API key. The API key is only checked when submitting a POST request… so I don’t think it has to do with that. However, restarting the server might help. Also, are you able to PING the IP address of the AWS server?

I do get a ping back from the AWS IP address, and the browser displays compute.rhino3d when I type just the public address (without the endpoint)

Do you get anything when you use the /healthcheck endpoint? It should respond “Healthy” if all is well. Also, have you tried sending a very simple Hops definition to this server? Make sure you enter the AWS server URL and the API key in the Grasshopper Preferences section. You may need to restart Rhino after you do this before you send the Hops definition over to that address.

/healthcheck returns healthy but /version or /sdk don’t work

I did try with hops and I get:

I tried this definition with compute running locally and it works.

Are you sure the definition that you’re trying to send over to the remote machine isn’t using a third party plugin that might be installed locally on your own machine, but hasn’t been installed on the remote machine? The reason I ask is that hops is clearly getting something back from the server because it populated the inputs and outputs (ie. Radius, Count, etc.). If it couldn’t communicate with the server at all, then that step would have failed. In addition, we know it’s likely not the API Key because to get the inputs and output response, hops sends a POST request and gets a response back which tells it how to build out the inputs and outputs. Before compute processes the POST, it check the authentication against the API key, so we likely know that part is working. My hunch is that there is a component that isn’t loaded on the remote machine that you’re trying to use and it’s failing at that step.
Can you do me a favor and simply try to load this file into Hops and send it over. It is a really basic grasshopper definition that I know contains know 3rd party components. (3.4 KB)

@AndyPayne I get this from running your definition:

I’m quite sure there were only native gh components in my previous definition. My guess is that in the previous screenshot that I sent it was the caché from running the definition locally providing inputs/outputs for hops

running SampleGHDelaunayMesh from the developer samples with my credentials gives me the following error:

Ok. Thanks for posting all of this. It appears to be the same issue as this user is having: Trouble following Compute Deployment tutorial. I am looking into this and will report back shortly.

1 Like

@dadandroid The errors you are reporting seem very similar to the ones reported in the other thread. In that thread, the user posted a copy of their log file which contained the error below.

System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.

Usually, these errors occur when Rhino fails to retrieve a valid license… which makes me wonder if there was a typo when you copied the Auth Token over in the bootstrap script… or if somehow it didn’t get saved into the environment variables correctly.

Here’s what I would recommend. First, goto this guide and follow the instructions on retrieving your Auth Token from the Rhino portal. Once you see your Auth Token displayed on the screen, click the “Copy” button to copy the entire string of text.

Next, go into your VM and click on the search bar and start typing “Environ”. You should see a link that says “Edit the system environment variables”. Click that and in the System Properties dialog click on the button at the bottom which says Environment Variables. In the System Variables list scroll down till you see the variable RHINO_TOKEN. Click on that row and select Edit. In the Variable Value input, replace the existing string with that you just copied from the Rhino portal.

Restart your AWS instance and then try to hit the /activechildren endpoint. Hopefully at this point, you will see an integer value greater than zero.

@AndyPayne manually setting the RHINO_TOKEN didn’t work but I managed to get some /activechildren finally after running the bootstrap again with a new token. Now Rhino opens in the VM and I can run your sample definition in hops :+1:

I am now able to run SampleTkinter from the python Developer Samples with my credentials, however I’m still not able to call compute from the browser using any of the other js dev samples. I keep getting the same error I posted above in the console related to CORS policy:

Do you have any idea what might be causing this? If it helps, here are the ports that are open in my instance:

I’d be happy to provide any additional info to make this work

more info:

Running your simple definition in a local compute server through the browser works:

Evaluating the same definition in the AWS compute server produces the same error in the console in the browser:

Access to fetch at ‘http://X.XX.X.X/grasshopper’ from origin ‘’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Using my compute address to run the definition in Hops works. Even evaluating the definition in python (Using export python sample... in hops) in my server does return a response with no errors:

My server seems to work everywhere but in the browser… Any thoughts @AndyPayne @will @stevebaer ?

So, I think the issue here is that you need to include your API key as part of the request header. Remember, when you ran the bootstrap script, it stored the API key in an environment variable. So, now when you make a request to your remote rhino compute instance, it will check to see if there is a value stored in that environment variable and if there is then it will check to see if they match before proceeding. When you run Hops (assuming you’ve installed the latest build and have input an API Key in the Hops Preferences section) this API Key gets sent as part of the request (in the header) so that the request is authenticated and the app knows that its “you” who sent the request. But, if you’re sending a request via some other means (a web request for example)… then you’ll need to also include the API Key as part of that request. The request uses a json object in the header to store the API Key. The key should be RhinoComputeKey and the value should be whatever your API Key is. So, something like this:

    "RhinoComputeKey" : "b8f91f04-3782-4f1c-87ac-8682f865bf1b"

Hopefully this helps. Let us know if this resolves the issue.

@AndyPayne I thought the Api key is being sent in the request if it’s included in the .js script by setting RhinoCompute.apiKey:

Is this not the case?

I can see that the request includes RhinoComputeKey in the header with a key that matches RHINO_COMPUTE_KEY env variable in the VM:

@AndyPayne so the Api key seems to be going with the request… any other thoughts on why I keep getting this error in the console?

Hi @dadandroid Sorry for the delay. Yes, I think you’re right. I think you’ve got the API Key in place for the request header. I’m going to need to see if somehow IIS is messing with the CORS policy and if that’s why you might be getting this error. I’ll report back my findings.

1 Like

Hi @dadandroid
In your index.html page, you likely have a script tag. Something that looks like this?

<script type="module" src="./script.js"></script>

What happens if you add the crossorigin tag to that? So something like this?

<script type="module" src="./script.js" crossorigin="anonymous"></script>

Does that fix the issue you’re seeing?

Hi @AndyPayne. I’m afraid it doesn’t. The CORS error persists after adding the crossorigin tag :face_with_diagonal_mouth:
Are you able to replicate this issue?

In a production environment, we have to tell IIS to bind our rhino.compute.exe to a port (in this case port 80). So, any incoming http request (ie. from webcrawlers) was telling IIS to start rhino.compute.exe which in turn would launch compute.geometry.exe. The first thing we need to change was to add a middleware layer which would check for authentication. We were already checking for the API key, but that was happening inside the compute.geometry.exe. If the API keys didn’t match then it wouldn’t process the request. But, we needed that check to happen up one layer in the communication flow (inside the rhino.compute.exe). So, we added some code to make sure that only requests that contain the API get through and start the compute.geometry.exe application.

The next problem we ran into is that the default behavior for rhino.compute.exe was to automatically launch an instance of compute.geometry.exe whenever it started up. For normal local testing and development, this works perfectly since we want both projects up and running whenever we send a request. However, this didn’t work so well inside a production environment. This is because IIS handles the starting and stopping of rhino.compute.exe application based on incoming http traffic. It has a setting called Idle Timeout (we’ll reference this term later) which is set to 20 minutes. If no IIS doesn’t receive any new messages during that time, it shuts the rhino.compute.exe application down. When it receives a new message (again, this can be any random http request from a webcrawler robot), then it will start up rhino.compute.exe. We already modified the code so that those requests were being returned with a 401 status code (not authenticated unless they contained the API key)… but the child compute.geometry.exe was still set to launch whenever rhino.compute.exe was started. So, to fix this we created a new command line argument called --spawn-at-startup whose default value is false (which is what we want in a production environment). If we want compute.geometry.exe to be launched simultaneously to rhino.compute.exe then we simply pass this argument into the command line when the process is started (ie. when rhino.compute.exe is launched whenever Grasshopper starts up). Because of this change, we had to release a small update to Hops (version 0.11.0) .

Remember the Idle Timeout value which I referenced earlier? That’s the IIS setting which tells it when to shutdown rhino.compute.exe. The default is set to 20 minutes. We have a similar setting called idlespan which defaults to 60 minutes and it’s what rhino.compute.exe uses to determine when to shutdown the child processes (ie. compute.geometry.exe). Well, when the 20 minutes had elapsed, IIS was shutting rhino.compute.exe down which in turn would shutdown its children (40 minutes early). So, I modified the bootstrap script so that it now reads the idlespan value from the web.config file and sets the Idle Timeout value for IIS to be slightly longer than that timespan. This way, rhino.compute.exe will always be open a little bit longer than compute.geometry.exe which is what we want.

Lastly, we needed to address the CORS issue you posted about in this thread. We added some code to the rhino.compute.exe server so that the response will return with the proper headers so that web requests shouldn’t fail now.

So, you’re probably asking how you get the latest update code. Well, the simplest answer would be to create a completely new VM image and re-run the bootstrap script. This will pull down all of the latest code and get everything properly setup for you. If you can’t do that, please let me know and I will walk you through the process of manually replacing the rhino.compute files so you can get the latest ones on your VM.

Hi @AndyPayne,
Could you please provide some guidance on this replacement process ?
I feel my compute setup and RhinoComputeUser session have become a mess !

Hi @Sebastien. Could you provide some more info as to where you’re finding problems?