Post

6 followers Follow
0
Avatar

Question: How to reference password variables from script?

Hello,
Trying to make an http conneciton from a script tasks like so:
xlrConn = HttpRequest({'url': 'http://xldapnv03.paychex.com:5516'}, 'aferrari', 'mypassword')
this works fine.
However, instead of my password being in the script plain text, I was hoping to reference a release variable instead like:
xlrConn = HttpRequest({'url': 'http://xldapnv03.paychex.com:5516'}, 'aferrari', ${MY_Pass})
or maybe:
xlrConn = HttpRequest({'url': 'http://xldapnv03.paychex.com:5516'}, 'aferrari', releaseVariables['MY_Pass'])
These dont seem to work (understandably considering the passwords should not be able to simply be printed out).
Can you recommend another strategy for using a password variable in a script?
or I would be happy to use a CI if that is easier. Thanks for your help!

Anthony Ferrari

Please sign in to leave a comment.

16 comments

0
Avatar

Well... frankly, that is a bit more work than I anticipated.
However, I stumbled on this method for getting the restricted password values - and it seems to work.
I initially tried to use standard Map accessors, but I think they are probably blocked ("None" returned) but I noticed that you can cast the passwordVariableValues Map to a string and see the values that way. I wrote a small func to do this.
Any thoughts on if this is a good alternate approach?

# Get the desired key from the MapStr
def getMapValue(sKeyName,sMapStr):
  iTagEndPos = sMapStr.find(sKeyName) + len(sKeyName)
  iFindNextEq = sMapStr.find("=",iTagEndPos)
  iFindEltEnd = sMapStr.find(",",iFindNextEq)
  if iFindEltEnd == -1:
    iFindEltEnd = sMapStr.find("}",iFindNextEq)
  sFindValue = sMapStr[iFindNextEq+1:iFindEltEnd]
  return sFindValue

# Get our password value from the Release Password Map
sFindKey = getMapValue("RM1_Password",str(release.passwordVariableValues))
print('sFindKey=' + sFindKey + "\n")
sFindKey = getMapValue("RM2_Password",str(release.passwordVariableValues))
print('sFindKey=' + sFindKey + "\n")
Anthony Ferrari 0 votes
0
Avatar

Thanks Hes!...
but again...that seems like a lot more work just to get access to a password variable and send it to a sub-release.
In the future, it would be great if XLR could resolve the password to a hash value instead of what we get now ("None") - so it could be accessed and used without compromising the actual password. I know that sub-release task is a community plugin - not core, so this may cause a further complication :) anyway thanks again for everyone's time! I think I will continue to use my method as it is working (so far so good). If something comes along that makes this easier, I will switch.

Anthony Ferrari 0 votes
0
Avatar

Could you elaborate a little bit on the use case? I'm interested in what problem you're trying to solve.

Note that our upcoming version, XL Release 4.8, has a complete overhaul of the variable system. I want to make sure we provide a sensible solution.

Hes Siemelink 0 votes
0
Avatar

Just checked XLR 4.7 and 4.8 and the best way to get a password in a script task is by getting the password map:

getCurrentRelease().passwordVariableValues

You need to set a "Run as..." user on a release because you're accessing the API.

A slight complication here is that the keys are of the format ${password} -- if you use this form directly, XL Release will try to resolve the ${password} variable before running the script and it will fail, because it is a password. You need the following trick to get to the variable:

getCurrentRelease().passwordVariableValues()['$' + '{password}']

Note that you have to call getCurrentRelease() and should not use the release variable in this case.

Hope this helps

Hes Siemelink 0 votes
0
Avatar

Hes, that worked perfectly and is easier than my method. I had to modify the call slightly to work in my script task:
release.passwordVariableValues['$' + '{RM_Password}']
Thanks!

Anthony Ferrari 0 votes
0
Avatar

Also - here is my use case where I am needing access to the pw variable
1) Release engineer launches XLR Release (types in username and password).
2) various tasks are performed, XLD deploys, manuals, scrips, etc.
3) At some point, a sub-release is executed....I do not want the Release engineer to re-type their password into the sub-release task. Instead, I want to pass it in from the parent release. This will be used for all sub-release tasks including more XLD deploys, etc.
Currently: I send in the parent release ID to the sub-release as a variable where I get the parent release object and then get the pw they originally typed in. I then use this in value the sub-release.
Hope that makes sense! Thanks again!

Anthony Ferrari 0 votes
0
Avatar

So it's like a workaround for not being able to pass password variables when starting a release?

I'm glad to say that that issue will be fixed in XL Release 4.8. (Coming really soon now, to be expected at the end of this month)

Hes Siemelink 0 votes
0
Avatar

Hi Hes and All,

Hes, in your final comment you say we will be able to pass password variables to a new release in 4.8.   Are we talking about via the sub release plugin or do you mean via the API or some other method?

We definitely are hung up currently on a clever way to kick off sub-releases using the credentials of the person who owns / started the parent release.   I would love to hear about any other options for doing this.

Thanks!

Bernie

Bernie Bonn 0 votes
0
Avatar

Hi Bernie

> Are we talking about via the sub release plugin or do you mean via the API or some other method?

I think Hes may have been referring to the releasePasswordVariables parameter to the /api/v1/templates/.../create and /api/v1/templates/.../start calls. Those should indeed allow you to set the values of password variables in a new release, but from your comment I'm not sure whether that would help address your issue.

Are you looking to ensure that a new release is created with a specific user as the release owner? Or with a specific user as the scriptUsername and corresponding scriptUserPassword? Or something else?

Regards


Andrew

Andrew Phillips 0 votes
0
Avatar

Hi Andrew,

Thanks so much for reaching out.  I indeed saw that new api call you reference but I saw that it passes a map of strings which wouldn't be great for us.  So we would have to hijack that users password and put it into an api call, unless I am missing something.

The use case is a Release Manager type starts a parent release that will go through a couple of environments each environment is a phase and each phase starts a sub-release that does most of the 'work'.   So that user is the release.owner, and when they create a release they will put their password into a password variable field.  Now what we are looking to have happen is to pass the release.owner and password variable to the sub release.  Because these users have the proper permissions in XLD to do deploys.

So the sub-template gets launched and that is where we have our XLD tasks to do our deploy among other types of tasks.  (We use the community XLD plugin btw).   

So this is sticky, I wonder if I am missing any easy answers.  

Thanks as always for any guidance,

Bernie

Bernie Bonn 0 votes
0
Avatar

Hi Bernie

Here's my summary, is this correct?

  • Release Manager Mary starts Release A and types in her password. The password is stored in a variable, let's say ${deploymentPass}
  • Release A kicks off several subreleases: B, C and D, that do the actual deployments
  • The subreleases have XL Deploy tasks configured with an XL Deploy server, but still need username & password to work.
  • So when starting the subreleases we need to pass user ${release.owner} and password ${deploymentPass}

We are currently implementing the "Start subrelease task" as a core feature for the upcoming XL Release 5.0.0 release (scheduled late April) and will keep this usage scenario in mind.

Kind regards,

Hes Siemelink 0 votes
0
Avatar

Hes,

You nailed it!  Is it done yet?  :)

Thanks let us know if you need early testers.  

Thanks for your help,

Bernie

Bernie Bonn 0 votes
0
Avatar

Hey guys,

this works fine for local variables:

release.passwordVariableValues['$' + '{my_password_var}']

 

is there a similar way to retrieve the values of global password variables?

 

thanks a lot,

Marius

Marius Manea 0 votes