Hi!
We released a new version of the Python API, v3.3.1. Here are the release notes.
- Implements retries with incremental backoff on 502 errors.
As always, feel free to reach out to our support team if you have any questions or concerns!
1 Like
Is it planned to update the API to use Autodesk Credentials for logging in as HumanUser? At the moment the OLD migrated accounts have to provide old SG-Username and old SG-password PLUS the PAT. The new accounts, created after the migration use the ADSK creds. Why the inconsistency, and what’s the roadmap for this feature?
First, please allow me to correct you : a new ShotGrid account on a site using Autodesk Identity does NOT use the Autodesk Identity credentials.
New users are created with a login that match their email (if that login is not already taken), and does not have a password (passphrase) set. It is the user that decides what it is. Obviously, picking the same password as your Autodesk Identity user is possible but definitely not mandatory. A user will not be able to leverage a Personal Access Token (PAT) associated with their user if there is not a passphrase set by them.
Now regarding your question: there are currently no such plans.
As things currently stands, logging into Autodesk Identity with credentials can only be done via a web-like environment. There are no ways to send your credentials over-the-wire via a simple API call.
Autodesk Identity supports its own 2FA mechanism, which would make it more difficult to connect directly via an API if such a thing existed. But Autodesk Identity also allows company to tie in their own SSO backend to the authentication process. Effectively making it nearly impossible (due to the variety of IdPs available) to define an API that would provide a unified solution.
This is why the idea of a PAT came on the scene: it is recognized by Autodesk Identity as identifying a specific user and allows code to exchange it for a session token. To make things safer, the PAT is kept in ShotGrid and it is the only one that can make the request to exchange it for a session token.
When using a PAT, you should see ShotGrid as a password manager: you need to enter valid credentials to unlock it. Doing things this way is safer than having user handle the PAT and pass it along. There are two levels of control/revocations : you can change your passphrase in ShotGrid or delete the PAT from your security settings on profile.autodesk.com.
Another reason for having a PAT : it ensured that no software update was needed for your applications/scripts when your site transitioned to Autodesk Identity. If an artist was able to connect on day - 5, they would also be able to connect on day + 5 (provided a PAT was set)
So we understand the potential discomfort of having a different set of credentials between Autodesk Identity and the ShotGrid legacy username/passphrase, but the benefits seemed to outweigh the drawbacks.
At this time, a user can set their passphrase to match their Autodesk Identity password. But there is a bug (which is currently being actively worked on) where a ShotGrid admin cannot change an existing user’s login.
Once that is fixed, there will be the possibility to have credentials that matches between ShotGrid and Autodesk Identity, though it would rightfully be argued that this may be a security risk.
Should you want to use really use your Autodesk Identity credentials to authenticate with a script, you can get an insight on how to do that from this post: Python API/Rest API and authentication with SSO enabled
Hoping my explanation to be satisfactory,
-Patrick
Yeah, you are totally right about the passphrase, but let’s be honest, how to hell an Artist could find out on his own, how to login with all those credentials to setup in the first place.
Even the binding of the PAT is a thing, every Artist just skips. Is there a official documentation which describes everything about the new login system End-User and API authentication. In-depth. For migrated accounts and for those created after migration?
This is the guide I send every artist to:
Is there something like that about the API authentication? Something about the Legacy Login and the passphrase?
So I’ve got a wonderful case for you. We have a freelancer, who was invited on april 2021st and started today. He didn’t created any passphrases, but there is one. He can’t change it, because, he never had set the passphrase. I’m as admin cannot do it either. So what’s the way to get him working?
Indeed, this is a pickle…
If that user has never done any work (since they only started today), one option would be to simply de-activate and trash the user they have right now and re-invite them. So no history lost.
Otherwise, contact me via private message with your site and freelancer email. I’ll see if I can do something
-Patrick
Sorry, I missed your previous message regarding documentation. In the migration-related documentation, there is this FAQ: Help
-Patrick
Hello all,
This seems a rather complicated thing to do for developers in the middle of a production.
1.- I understand that if all my users have already started using our Shotgrid acc. prior to the migration, they should all have a passphrase, as that passphrase is the legacy login right?
2.- If all my users already have an ADSK acc. and they have all logged in at least once, they only need to create a PAT in the ADSK profile page and bind it in the SG Acc. page for all my scripts to work?
As far as I have understood, no script would need to be changed in my pipeline right?, but if we rely on HumanUser login with methods such as cs.sg.authenticate_human_user() (which uses the password that users used to use for login prior to ADSK loggin, I think you call this passphase), having the users bind a PAT shoul fix that?
I just find it hard to check whether everything will work just fine in my pipeline before doing the migration, is there a way I can test all these things without pressing the red button and hoping that we did all correctly?
Thank you for your time @patrick-hubert-adsk
1 Like
Hi @j.moraga
- exact
- correct
As described in our FAQ, the only scripts that would need to be changed are those that:
- sets the
sg_status_listof a HumanUser toact - creates a new active HumanUser
In these cases:
- the script cannot connect with a Script Name/API Key. The authentication must be made with a legacy username and a passphrase, with an admin user with a valid Personal Access Token.
- the user doing the action cannot be the target of a sudo_as_login.
Any API authentication on a migrated site using the legacy login and passphrase will fail if a valid PAT is not set for that user. Admittedly, it is not obvious to end users (programmers and artists alike) how the tools they use connects to ShotGrid. So the safe thing to do is to ask all your users to set a PAT.
As for checking that the code path on a site mid-migration (e.g. the login page shows 2 login buttons): if a user has set a PAT for their user, it will be used.
An easy way to test that:
- clear any existing PAT on a user,
- define a new one in
https://profile.autodesk.com/security - save it to your ShotGrid user
- BUT then go back to the profile and delete the PAT before your first use of it !
- then run your scrip / app, authenticate with the legacy login and passphrase, see the error about the invalid PAT.
The reason I say to delete it immediately before its first use : once a PAT is exchanged with Identity, the user will be considered logged in and the PAT will not be re-check until 1 hour has passed or more.
The idea here was for the API to offer a validation of the Identity flow if all the pre-requisites were present (the same way that the Web login offers the 2 login buttons during the hybrid phase)
-Patrick
1 Like
Hello Patrick,
Thank you very much for your time, I think you have cleared out all my doubts… at least for now.
I did try your method for testing this out and you are right it wouldn’t let me log in after I removed the binded PAT from the Autodesk Acc.
As for having API scripts managing HumanUsers, we don’t have them, we do it all through the website, so everything should be alright.
Have a nice day,
1 Like