VMware Cloud Community
craigso
Enthusiast
Enthusiast
Jump to solution

Property not being passed to Software Component script

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.

pastedImage_1.png

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.

pastedImage_2.png

3. These values are passed to a script which are configured:

pastedImage_3.png

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:

  • Values of the hidden form elements are populated for all users requesting it, so they should be getting passed to the software component.
  • Moving the property to a custom property defined in a property group and using that in the software component still doesn't allow for the value to be passed
  • Marking the value as 'show in request' does not pass the value
  • The $zone variable passed with no issues, while $vraUser does not, unless you are a privileged user. Both properties are configured the same way and in the same software component.

As always, thank you for taking the time to read this thread. Any input here would be helpful!

1 Solution

Accepted Solutions
craigso
Enthusiast
Enthusiast
Jump to solution

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

pastedImage_1.png

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'

pastedImage_1.png

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.

View solution in original post

17 Replies
daphnissov
Immortal
Immortal
Jump to solution

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.

craigso
Enthusiast
Enthusiast
Jump to solution

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.

  • The zone property get passed with either a normal user or admin. It also binds to another property, similar to vraUser.
  • I tried removing the property from the SC, recreating it in a property group(checking the show in request flag), then referencing this property in the SC.
  • Are you saying if property2(copy) binds to property1(source), then the show in request flag needs to be set on property1?

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

craigso
Enthusiast
Enthusiast
Jump to solution

I just finished testing this after making the change. Here are my findings.

1. modified the properties to required:

pastedImage_1.png

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.

pastedImage_0.png

pastedImage_2.png

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

Can you show how/where the zone variable is getting presented on the custom form?

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

Sure! The setup for the Zone property currently looks like this:

Property group 'base' contains a property called Base.NetworkZone

pastedImage_0.png

We add that to the custom form as a dropdown

pastedImage_2.png

This gets it's default value and value options from actions. (I can elaborate a bit more here if needed)

pastedImage_3.png

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.

pastedImage_4.png

Please let me know if I left anything out. Happy to elaborate further.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

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:

pastedImage_0.png

And also by marking as required of the properties within the software component:

pastedImage_1.png

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

craigso
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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:

  1. If the request will fail without a value, that property (custom or software component) should be required. No exceptions.
  2. If the user needs to provide their own input, that field should be shown on request.
    1. If you show it in the request, you need to provide a value regardless of how you use that later.
craigso
Enthusiast
Enthusiast
Jump to solution

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'.

pastedImage_5.png

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:

pastedImage_7.png

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.

pastedImage_10.png

(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:

  1. Recreated the property with a different name
  2. Mark it as required and 'show in request' (This is done in the software component and in the config when the software component is added to the composite blueprint)
  3. Edited the custom form removing the reference to the old property, and adding the new one.
  4. Reconfigured the new form element, values, binding, visibility, etc.

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.

Reply
0 Kudos
craigso
Enthusiast
Enthusiast
Jump to solution

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

pastedImage_1.png

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'

pastedImage_1.png

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.

Vsure
Enthusiast
Enthusiast
Jump to solution

Can I assume your users are not members of the "Support" or "Manager" roles in the Business group?  There us a known issue and PR open for needing to "Show in Request" in order for Custom Properties to be passed to vRO.
Reply
0 Kudos
daphnissov
Immortal
Immortal
Jump to solution

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.

craigso
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos