Is there an API3 alternative to the old login/logout methods? Basically, just looking for some way to authenticate a user via script. Like say, I want to run a script where I feed it my username/password (along with the api key obviously) and the script authenticates that the correct username/password combination was used and then does something relevant, like lists all the shots assigned to me, or something like that.
Date
Votes
12 comments
-
Jake Wilson Looks like the closest thing I can find in the methods is doing a find('HumanUser') where login=<name> and I see the password_proxy, but I can't figure out a way to test against it, since its really not a hash value of any type....
-
KP We're working on this for some integration work we're doing right now, but it's not quite ready for public release. The majority of standalone scripts that our users are running don't need to run in the context of a user. However, with the more integrations we do, we're starting to address that need and as I mentioned, we're testing user based authentication as part of that.
To address your followup comment, password_proxy isn't available for read or update via the API for obvious security reasons.
What is it exactly you are trying to do?
-
Jake Wilson What I'm trying to do can be summed up with an example:
Lets say you have a script that an Artist or some other person uses to query the Shotgun server for what Shots/Assets/etc are assigned to them (they are linked to it or it is relevant to them in some way). The script would obviously require someone to put in their Shotgun username in order for the script to make the query and return the proper information.
Now obviously, that particular example does not necessarily require any type of user authentication because the script could easily find Shots/Assets/etc that are linked to any HumanUser. But when you start considering permission issues, sensitive information and multiple teams working on a single Shotgun server, in many cases, a high level manager might not want certain individuals or certain groups/teams to be aware of what other people are working on, what shots are assigned to them, etc...
Taking the above example, lets say user "John" put in his Shotgun username into the script and it retrieved the information he wanted to see that was relevant to user John. Thats great. However, John could also just stick in another users name or even his managers name and see all the information pertinent to those users as well, even though in the Shotgun web interface, John doesn't have access or the proper permissions to view that information or he isn't linked to certain projects that all of the sudden he would have access to through this script. Since there is no way for the script to actually authenticate who John is trying to use the script as, there is no way for the script to come back and say "you can't query that because you don't have the proper permissions for it" or "you can't query that because you aren't linked to that project".
The thing about developing with an API is that a programmer is effectively able to bypass many security and permission-related features of a system because they are practically making direct queries with the database. I believe that its a programmers obligation to make sure that if they are developing something like this, that it's as bulletproof as the web gui and that it cannot be used by end-users to circumvent permission or security features.
Now in a perfect world, a team (or teams) that use a Shotgun server is completely open with each other about everything and it really doesn't matter who knows what who else is working on, etc. That is most likely the case with most studios. But even then, I can image certain big projects for companies still are kept hush-hush even internally, so that leaks to media don't happen before the project is revealed. Also, some users (especially managers) might store certain key sensitive information within Shotgun that they might only want certain individuals to have access to. A good example would be project budget information.
Anyways, I could keep going, but I think you get my drift. I know that I viewed the login/logout methods of api2 to be valuable (even if not used that often) and I'm looking forward to the user based authentication you speak of to make its way into api3.
-
KP Yep. Definitely true. Most of the devs writing tools are writing them to automate workflow in order to hook Shotgun up with their pipeline. And these tools will be pulling in information for any number of users and entities throughout Shotgun. So in general most of these types of scripts need unfettered access to Shotgun. But your point is completely valid and we agree. Which is why we're moving on to this type of authentication as well. Thanks for sharing your thoughts. We'll let everyone know when we have user-based authentication enabled in the API for sure.
-
Jake Wilson Rock on! Thanks for the quick reply, Kevin!
I'm not sure if you guys have considered how to implement it in the script interface, but I'd imagine that a straightforward way to do it would be that when you create a Shotgun object, that you could optionally pass a username/password as arguments, along with the script name and api-key.
Any rough guesstimation on when it will be added to the API? 1 month? 6 months? 12 months?
-
KP No hard estimate yet. But I can say "soon". ;)
-
Jake Wilson "When its done" ?? :-)
-
Jake Wilson Hey guys, just wanted to see if this feature had been considered to be added to the roadmap yet?
-
Jose Chin Hey guys, after 1 year the user-based authentication is enabled in the new API3?.
-
Jake Wilson Hi Jose,
I'm not sure if it is public knowledge or not (I don't see it anywhere in the documentation that I can find...) but instead of passing a script name + script key when you make the API connection to the server, you can instead pass a username + password. I'm not sure this works with the as-is Python API3 or not, but I know if you drill down and use some of the underlying base functions, you can authenticate using this method.
-
Mike Tuffy I have forked the current Shotgun Python API and exposed that technique when creating a Shotgun instance. Instead of the usual script name and key you can pass in a user's login, their password and set the user_auth arg to True. e.g.
sg = Shotgun('http://shotgunurl', 'login', 'mypassword', user_auth=True)
It is up on my Github: https://github.com/MikeTuffy/python-api. It would be useful if something like this was added to the actual Shotgun API - I notice that there is also a new 'authenticate_human_user' method in the Trunk but that still requires connecting via a script user and key initially as far as I can tell.
Cheers,
Mike
-
Brendan Abel This is especially useful for distributing tools to offsite users, since you don't want to have to distribute admin-level credentials to everyone that is going to use your tools.
For those interested, you can user user credentials instead of script credentials with the standard shotgun api by setting the user_login and user_password attributes on the shotgun config object. Big thanks to Mike Tuffy for his fork which does this more elegantly. I would vote for rolling that change into the standard api as well
sg = Shotgun(base_url, username, password)
sg.config.user_login = username
sg.config.user_password = password
Please sign in to leave a comment.