ContributionsMost RecentMost LikesSolutionsSoap UI Support for Multiple Scopes in OAuth 2.0 Authorization/Get Access Token Hello, When attempting to get an OAuth 2.0 Access token using Authorization/Get Access using more than one scope separated by spaces I get an Invalid Scope error from the authorization server. I am able to make the call using other API tools without an issue. Is there something special in SoapUI that needs to be done and/or a special way to delimit multiple scope values? Thank you, Ron Re: Disable Property Expansions Rao, Thank you for responding and I will definitely try to show an example. At a very high level we have implemented a third party product that provides migration functionality that allows us to export policy definitions from one environment to another. In essence they provide get and post methods that we invoke using SOAP UI. Within a policy you can create variables that use a ${variableName} parameter. Here is an example of a section of XML that is produced via a get method sent to the export service using SOAP UI: <L7p:ComparisonAssertion> <L7p:CaseSensitive booleanValue="false"/> <L7p:Expression1 stringValue="${entryPoint}"/> <L7p:Expression2 stringValue=""/> <L7p:Negate booleanValue="true"/> <L7p:Operator operator="EMPTY"/> <L7p:Predicates predicates="included"> <L7p:item binary="included"> <L7p:CaseSensitive booleanValue="false"/> <L7p:Negated booleanValue="true"/> <L7p:Operator operator="EMPTY"/> <L7p:RightValue stringValue=""/> </L7p:item> </L7p:Predicates> </L7p:ComparisonAssertion> We would then use the import service via a put method to migrate the policy definition to a new environment. If we were then to export the policy definition from the new environment it would look like this: <L7p:ComparisonAssertion> <L7p:CaseSensitive booleanValue="false"/> <L7p:Expression1 stringValue=""/> <L7p:Expression2 stringValue=""/> <L7p:Negate booleanValue="true"/> <L7p:Operator operator="EMPTY"/> <L7p:Predicates predicates="included"> <L7p:item binary="included"> <L7p:CaseSensitive booleanValue="false"/> <L7p:Negated booleanValue="true"/> <L7p:Operator operator="EMPTY"/> <L7p:RightValue stringValue=""/> </L7p:item> </L7p:Predicates> </L7p:ComparisonAssertion> In this example SOAP UI is replacing the variable ${entryPoint} with an empty string. An example of what a Policy would like from the third party GUI is as follows: Add Audit Details: “Policy Fragment: aPolicyFragment” Compare Variable: ${entryPoint} is not empty; If Multivalued all values must pass Include Policy Fragment: aPolicyFragment2 In the end we do not want SOAP UI to expand the ${entryPoint} variable as that variable is needed within the third party policy. Does that help explain issue. Regardless thanks for your help. Ron Disable Property Expansions We recently discovered an issue with SOAP UI where a third party products variables were being "expanded" because they use the same ${variable} format as SOAP UI. By "expanded" I mean they were being replaced with an empty string. After doing some research I found that the SOAP UI NG Pro has a feature where you can disable property expansion. I downloaded the trial version of NG Pro and verified that this feature is there and sure enough I was able to disable property expansion. Does anyone know if there is a similar feature in SOAP UI and how it works? If this feature does not exist in SOAP UI is it on the backlog for SOAP UI? Thank you, Ron