The auth.login API method returns a token that is used for all of the other API calls to determine authorization. The token will expire after a certain amount of time.
If you are looking for a way to get and store a credential session for repeated use or other scripts / calls, I solved it by creating a local "session cache" that was checked before prompting for the password again. I also used python getpass module which treats the input specially. You can see what I'm talking about here on github. https://github.com/nzwulfin/spaceclone/blob/sessions/src/spaceclone/satellite/satellite.py That's the main generator gets called by the modules that do things to instantiate a Satellite object. Anyhow, cached API tokens, no storage of the password in the prompt. Cheers, Matt > -----Original Message----- > From: [email protected] [mailto:spacewalk-list- > [email protected]] On Behalf Of Grant Gainey > Sent: Thursday, May 08, 2014 6:08 PM > To: [email protected] > Subject: Re: [Spacewalk-list] API using hashed SATELLITE_PASSWORD > > ----- Original Message ----- > > We would like to use a hashed password with the API. Example below: > > Your example seems to just use the API with a password like usual? > > > > > # !/usr/bin/python import xmlrpclib > > > > SATELLITE_URL = " http://satellite.example.com/rpc/api " > > SATELLITE_LOGIN = "username" SATELLITE_PASSWORD = "password" client = > > xmlrpclib.Server (SATELLITE_URL , verbose = 0 ) key = > > client.auth.login (SATELLITE_LOGIN , SATELLITE_PASSWORD ) list = > client.user.list_users (key) for user in list : > > print user.get ( 'login' ) client.auth.logout (key) > > > > > > Will this cause any problems in other areas? Will it work at all? > > What are you trying to accomplish, really? > > If it's "tell customers that their password is never known by the SW > server" - well, let's see. You could set up their accounts by asking > them for a password, salt+hash that string, binhex it, and use *that* > as their SW password. Then, to use the API, give them a > script/application that asked them for their 'real' password and > replicated the process before talking to SW. Basically, the salthash'd > string *is* their pwd, from SW's POV, but SW never knows the string the > user remembers. > > On the other hand, if you're trying to protect your SW admin's pwd from > prying eyes - well, sooner or later, *something* has to call login. > And whatever you call the Thing that login accepts, it needs to be > secure, or a nosey user of your script is still going to end up with > the ability to trash your SW instance :) > > But I think maybe I'm not understanding what you're trying to do. Can > you give us more context? > > G > > > > > _______________________________________________ > > Spacewalk-list mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/spacewalk-list > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
