Hi all,
can somebody explain some pros and cons for using a script name/key vs using Personal Access Tokens?
Obviously the premissions will be different on the SG side and with PATs I have to get everybody to generate and bind one first, but are there other differences I should be aware of before I decide to change my scripts to use PATs?
Cheers,
frank
What is the motivation to switch? For automated processes, script keys work great.
It is somewhat pointless to impersonate a human user, and as you said script keys give you more fine grained control over permissions.
Perhaps there are valid use cases for human users. One might be a standalone program, operated by the user, but the user does not login and the program handles authentication.
I am mostly wondering about a standalone app we use for publishing versions.I find myself giving out this app to freelancers and partner companies more these days and thus was reconsidering security.
Currently I am leaning towards keeping the script and obfuscating/encrypting the saved key. For PATs I’d still have to protect the user’s password when saving it so they don’t have to log in all the time. I guess I could use the operating system’s password manager in both cases. I’m not too experienced with this. I have done it once and it was a bit of a PITA.
So yeah, just wondering about that part, hence my contemplation to switch.
Slight tangent:
is it possible by now to set up an API script that only has access to a certain list of projects? That would be exactly the sort of script/PAK hybrid that would be perfect for us.
There is also the option of using the OAUTH API and leveraging a lot of work already done around security. Haven’t dug too deep into it, but I believe toolkit already has some abstractions for making it easier (unless you are using the REST api, in which case see the link above).
This way the users would log in with a standard Autodesk dialog, and you would receive an auth token that expires, etc.
It does have a learning curve, but would be more robust than rolling your own solution.
tbh I don’t see great cases for using PAT. Might be wrong, though.
Hi @frank
By default, API Script are using the API Admin permission group.
To have an API Script that only has access to certain projects, I believe that you would need to create a new permission group which has Advanced -> See all Projects unset.
There is a field Projects for API Script, so you would put there the projects it has access to.
I have not tested this.
That being said, that sounds like you are trying to circumvent security by obfuscating/serializing credentials, and making audit of past actions difficult or even impossible… I would advise against that.
-Patrick
Thanks @patrick-hubert-adsk , I have actually set up a api admin permissions with read only permissions which works fine. However, that does not give me the per-show permissions I was hoping for. Essentially I would like to be able to assign show access to individual scripts, so that they only have access to those (just like human users).
As for your last comment, maybe I didn’t explain this right, I just meant obfuscating/serialising locally, if I ever want to store login credentials for a user for conveninance. Just to avoid having those details as plain text on the local machine. But that is a lower priority right now.
Hi @frank
I would need to investigate further… but I am on vacations for still 10 more days. I just did a quick tests and I believe that there is a bug regarding the visibility of projects for an API Script (when the permission are set not to see all projects).
I would suggest that you open a ticket for this issue. So that it is tracked and you can be notified of the investigation results and the fix.
As for the serialization aspect : if there is one thing to serialize, it should be the session id, not the user/script credentials. Sessions expires and can be terminated. Credentials are way more valuable than a session id.
-Patrick
Thanks Patrick,
so you are saying the projects field for Script entities should actually do what I want, except it doesn’t. Will log a ticket.
Thanks for your comment regarding session id vs user deets, that makes perfect sense. I will read up on how to properly use session ids when I get to that point.
Cheers,
frank
how do I log a butg these days? That option has disappeared from SG. Can’t find anything in my autodeask accoutn either.
Found it somehow, though I am still unsure how I did it.
It would be nice to have a link back in the help menu so you don’t need a million clicks to report a bug or feature request. The current system is a sure fire way to silence any user feedback.
I just got word back from support.
The solution is to uncheck “see all projects” for the assigned script permission, then the project field behaves as expected.
Funny… this is exactly what I was doing…
I’ll check again.
-Patrick
My apologies @frank , there is no bug.
Un-checking see all projects will indeed work as intended.
What threw me off : even though I only have access to my script to 1 project, the list of projects returned from a simple sg.find('Project', []) had 10 entries.
I did not realize that 9 of the 10 entries where the template projects.
The only active project returned from sg.find('Project', [['sg_status', 'is', 'Active']]) was indeed the one I had set for it.
My apologies for the confusion I introduced, and you losing time with a support request.
-Patrick
No worries at all, I’m glad this is working as intended
ShotGrid is my daily driver but even then this happens to me too from time to time 