[Spacewalk-list] API using hashed SATELLITE_PASSWORD

[Matt Micene]

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: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
> bounces at redhat.com] On Behalf Of Grant Gainey
> Sent: Thursday, May 08, 2014 6:08 PM
> To: spacewalk-list at redhat.com
> 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
> > Spacewalk-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list
> 
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list