@teocomi, if I’m to understand this correctly, this functionality already exists, and the process would be something along the lines of:
User visits a web app and authenticates with speckle
User token added to %appdata%\Speckle\Accounts\ on VM with RhinoCompute and Speckle installed
User uploads a GH script to run remotely
GH script is sent to RhinoCompute VM via Resthopper endpoints
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).
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.
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.
We’ve already starting working on the auth changes needed to make this happen. I’m hoping to have them merged soon and make a pre-release so you (and the rest of the community) can give it a go before we settle on any particulars.
I forgot to ping you back on this, but 2.12 contains the new nodes described in the PR linked above.
Feel free to give them a go and come back to us with any feedback. We’re also in conversations with other users about how to improve this workflow and how to minimise the amount of changes required to a GH script to get it running on compute properly, so anything in that regard would be appreciated!
Hey @AlanRynne just got a chance to test these tonight and this is looking great - good balance of flexibility and providing tools to set things up securely. I’ll have more of a play and update with any feedback!