We are experiencing an issue where a variable is not getting passed to a script within a software component for non-admin or non-privileged users. This issue seemed to be similar to a post I made last week where custom properties were not getting passed to the event broker payload.(Link: Custom Properties not being passed in Event Broker payload? ) However after some additional testing, it appears it's not the same issue as far as I can tell.
We are running vRA 7.6
The issue:
We need to pass a username from a text field on a custom form and pass to a software component. This software component runs a script located on a provisioned VM. If a non-privileged user (blueprint shared access role, no other roles) provisions a VM, the variable is not passed. If an admin request the same blueprint, the variable is passed.
Here is the setup in detail:
1. We pull in a username from "requested for" then pass it off to an action to strip of the @domain.com. We are left with just a username.
2. We have a software component that defines two properties zone and vraUser. We place those on the custom form (hidden), and bind other fields on the form.
3. These values are passed to a script which are configured:
Install Script -
The $zone variable gets passed for both privileged and non-privileged users.
## Install Script
# Set PATH
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/root/bin
###
SCRIPT="base_install.sh"
curl -o $SCRIPT https://satellite.domain.com/pub/provisioning/$SCRIPT
chmod +x $SCRIPT
./$SCRIPT $zone
Configure Script-
This is where we are having issues with the $vraUser variable getting passed:
## Configure Script
# Set PATH
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/root/bin
###
SCRIPT="base_configure.sh"
curl -o $SCRIPT https://satellite.domain.com/pub/provisioning/$SCRIPT
chmod +x $SCRIPT
./$SCRIPT $vraUser
At the top of the base_configure.sh script we print the value received so we can determine if it's getting passed.
# Set PATH
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/root/bin
###
echo "Username is: '$1'"
A few things we have confirmed so far:
As always, thank you for taking the time to read this thread. Any input here would be helpful!
I just finished modifying our other blueprints that shared these software components and I figured I would share the process I found required to get these properties to pass.
1. Modify the properties in the software component to be required
2. Delete the software component from the Composite Blueprint, then re-add it.
3. In the composite blueprint, go to the software component -> Properties. Edit the properties to be required and 'show in request'
4. Go to the custom form, delete any existing for elements added by these properties. Then add required properties back and reconfigure appropriately.
After those 4 steps are completed, the values should get passed to the software components.
---------------------------------------------------------------------------------------------------------
Was it helpful? Let us know by completing this short survey here.
Hi again. This is the same issue as what we mutually found in your previous post. Screenshot #2 clenches it: You have two properties on your software component (SC) that are marked as show in request = no. These become fields on a custom form which are hidden and bound from other fields. But when those SC property fields are exposed they carry the "show in request" flag with them. Based on the response I received from engineering, this is not a bug but rather intended behavior that was altered due to a perceived security hole. I'll post the comment I received in your other thread for further detail, but this explains both issues.
As an aside, you're adding what I would consider an additional and unnecessary step in your custom form by calling an action to simply strip out the @domain.com portion of your username field. When I've built SCs like this in the past, I'd just pass that field value straight through to my SC and use sed to strip out the text that I want. This is very simple to do with bash and on any Linux distro. The choice is yours, but personally I wouldn't complicate my blueprints any more than necessary by invoking such an action.
Thanks for the reply.
You reference the second screenshot, but I don't see where there is an indicator of show in request? Is there something else that indicates this to you?
As I read your response here are a couple other notes regarding this config.
Also regarding the action for modifying the username, we use use this action in workflows/actions to handle the usernames. Since our domain is name@sub.domain.com we need to convert to name@domain.com for emails, or just grab the username. For this property, we just use it to be consistent. I agree with you it complicates the setup a bit. Thank you for the tip, we may look into doing that (or similar) with our Linux hosts.
For the time being, I'll go back and do some more testing with show in request and these properties.
You reference the second screenshot, but I don't see where there is an indicator of show in request? Is there something else that indicates this to you?
You have "required = no" which, when exposed in the request form is the same as "show in request = no". To test, change this property to "required = yes" and update the custom form and try again.
I just finished testing this after making the change. Here are my findings.
1. modified the properties to required:
2. Removed both custom form elements, and added them back to reflect the required field changes.
3. Requested the blueprint.
Here is the output of the script. We actually fail on the configure step, however you can see in the install step Zone is passed, Username(vraUser) is not.
Can you show how/where the zone variable is getting presented on the custom form?
Sure! The setup for the Zone property currently looks like this:
Property group 'base' contains a property called Base.NetworkZone
We add that to the custom form as a dropdown
This gets it's default value and value options from actions. (I can elaborate a bit more here if needed)
We then have the another zone property from the SC(hidden) that binds to the 'Zone:' field that is presented to the user. This is duplication and probably not needed, but it is working! Its hidden to non-admin users. This takes the value selected above and passes it to the SC.
Please let me know if I left anything out. Happy to elaborate further.
I added the user to the support role in the blueprint, and I can confirm the value DID get passed. So I think that's some confirmation... but still I don't understand what is different between the zone config and the user? I'd rather not grant access to the support role.
Sorry for the delay. In your custom form, the "zone" property is visible. I take it the vraUser is hidden? If so, this could be the reason.
No problem for the delay. Thanks for checking in again.
That's correct, zone is not hidden but vraUser is.
I was able to get the property to pass by setting required and show in request on the properties of the software component in the blueprint:
And also by marking as required of the properties within the software component:
So now that I've got the properties passing to this software component, I'm failing for properties on the next software component which is configured the same way. After attempting the same changes to these properties it's still not passing. Still seems like I'm missing one part of the equation to make this work. I'll post as I make more progress here.
I think the key here is your vraUser which is hidden on the custom form. That seems to be a common piece.
What about the next one that's failing? What helps me when debugging these things is to just echo out all the external variables ("Properties" on the SC) inside the script so you capture that in the output. You can see which ones made it and which didn't. Then you backtrack from there and start pulling apart the payload.
Yeah, the other property that isn't getting passed is also hidden.
good tip! I've been echoing the properties. It's a great way to figure out what made it like you said.
I'll try making the elements visible on the form.
After speaking with some other internal folks, the issue on the custom form is the fact that they're hidden. So, when it comes to your vraUser property, I would personally tackle that by making that a visible field that simply "echos" back to the user requesting the catalog item their name. No harm, no foul, and couldn't possibly be objectionable, right?
Aside from that, a design philosophy I follow and try and impart to others when it comes to software component design (and custom property design) is the following:
After getting the properties vraUser property to pass to the first software component, we found we had another property failing to pass. I'll describe the failure scenario and how I fixed it.
We have a single Composite Blueprint with several Software Components used for configuring the VM after it's provisioned. Currently we have properties defined in the software component, and those are added to the Custom Form via 'Show in request'.
As mentioned, we fixed the properties getting passed to one of the software components by making them required and show in request. We would then fail on the next software component for the same issue. Some of the properties would get passed and some wouldn't. Even after marking them as required and show in request, not all values would pass. The one value not getting passed was again a username field called VraUser. VraUser grabs it's values from another field on the blueprint. I've tried to illustrate that here:
You'll notice there are two 'vrauser' properties. There is one defined in each of the software components and they both are bound to the same property on the blueprint.
Our current forms are designed with a hidden automation element section. It is hidden based on being a member of an AD group. In this hidden section we have the three username fields.
(This is not good design! This will be replaced with a custom property that populates with the username. Then reference that property within the software components.)
Since the values were not passing for VraUser, I thought maybe there was a namespace collision with 3 fields named some combination of 'vrauser' with upper and lowercase letters. Still not sure on that, but again, poor design. I deleted the VraUser property that was defined in the software component that was not working. I then performed the following steps:
After completing those steps, the property value was them passed successfully. I've also tested with the form elements hidden and displayed to the user. Either case, the properties were passed successfully.
I just finished modifying our other blueprints that shared these software components and I figured I would share the process I found required to get these properties to pass.
1. Modify the properties in the software component to be required
2. Delete the software component from the Composite Blueprint, then re-add it.
3. In the composite blueprint, go to the software component -> Properties. Edit the properties to be required and 'show in request'
4. Go to the custom form, delete any existing for elements added by these properties. Then add required properties back and reconfigure appropriately.
After those 4 steps are completed, the values should get passed to the software components.
---------------------------------------------------------------------------------------------------------
Was it helpful? Let us know by completing this short survey here.
Yes, his users are not support or manager, that's why this is an issue. The PR isn't actually a PR and it won't be fixed. As laid out in linked threads, this behavior is intended and was developed to mitigate security concerns.
Another update for this particular issue. After getting all the issues resolved for the particular software component mentioned in this thread, the same issue came up with a different software component. The behavior was exactly the same, properties not being passed. But in that case with the properties configured correctly, the values would not get passed to the software component.
I tried cloning the software component and the issues followed the new component as well. The only fix I could find was to recreate the software component from scratch. I've got a case open with support to try to identify the root cause to prevent this from happening again.