Speckle Auth, Hops, and remote Rhino Compute

Building on the conversation started in Running Speckle on Rhino Compute

To my understanding, Speckle is now set up to work in a headless Rhino instance using Rhino.Compute, using the Speckle Manager to authenticate using the users details.

So a desktop user can utilise Speckle in a compute context, where the speckle workflow is 100% internal to the script and assuming there is a logged in user.

In a “truely remote” compute environment, a use case might be:

  1. User visits a web app and authenticates with speckle
  2. User uploads a GH script to run remotely
  3. GH script is sent to RhinoCompute VM via Resthopper endpoiints
  4. GH script executes using credentials provided by app

So you’d need some way to authenticate a Speckle node directly, so that you could provide the auth info through Resthopper?

There are a couple of ways to approach this so I’m interested in other people’s thoughts.

2 Likes

Hey @chris.welch!

Interesting suggestion, and 100% valid. Obviously most of the existing logic needs to be revised for this use-case, which I have already started thinking about during Christmas.

On this, what I had in mind is creating a new node that would have the token and server as an input and would spit out a correct account object or error out if the token is invalid.

I’m fairly certain this would not be “as magical” as it sounds, as it may involve some re-thinking on the account fetching logic on Core. Pinging @teocomi and @luisfraguada on this too!

Happy to hear your thoughts on this, and any alternative ideas you may have had in mind.

P.S. Not sure if passing in an auth token to a GH file as a plain text string is the best of ideas from a security perspective… :thinking:

Hey @chris.welch , see this info to set up accounts on the remote machine without the use of Manager:

Another way could be to have your own logic in C#.

We’ve been asked this in the past and our answer is that it could too easily lead to credentials being leaked, that’s why we’re a bit reluctant heading that way :wink:

3 Likes

@teocomi, if I’m to understand this correctly, this functionality already exists, and the process would be something along the lines of:

  1. User visits a web app and authenticates with speckle
  2. User token added to %appdata%\Speckle\Accounts\ on VM with RhinoCompute and Speckle installed
  3. User uploads a GH script to run remotely
  4. GH script is sent to RhinoCompute VM via Resthopper endpoints
  5. GH script executes using credentials within %appdata%\Speckle\Accounts\

If the user revokes the app then the token expires, as expected.

The only issue I could see there (which I haven’t tested) is that if multiple users added to that list have access to a stream, it might short circuit? (e.g user A and B have access to a stream and are authenticated with the app, user B uploads and runs a script that uses the stream, speckle GH node checks authenticated users in order and as A has access, commit has thier name against it).

1 Like

A cursory look with a new account with no permissions indicates that this is the case:

The expected behaviour woud be that sGet would return a null because the selected user doesn’t have permissions on the test stream, and the send and recieve nodes should also throw an error if a specific user is specified and that user doesn’t have permission. I think if that behaviour changed, then you could handle the rest of the auth just through Grasshopper, as the send and recieve would both be fed a null in the case that the permissions were incorrect.

2 Likes

Thanks for the detailed comments @chris.welch,

we’re already discussing some changes on these lines:

Currently, the sender outputs an “unauthenticated Stream Wrapper object”. Meaning, even if it did use the correct account to send, the output commit url will still be one with no account set on it. This is a fairly easy change to make.

The second issue is that Stream Get is in fact using a different logic to fetch the account than the one implemented in the StreamWrapper. This is yet another easy change that will result in the expected behaviour you described.

There may be other places where this change will make sense so I’ll have a look and open an issue about all this in our repo.

2 Likes

Cheers folks, I’ll keep this thread unresolved until those changes are implemented