We have SoapUI (Open Source Edition) installed on a windows jumpbox. Many users can login with their accounts, open soapui, import a wadl/wsdl from a dozen of projects and perform testing.
Since the IP is always same, we are unable to find who has sent a request and that is a problem when some destructive requests are made that causes lots of recovery issues (Only authorized users have the access).
Now we want to add http header like user : ${=System.getenv("USERNAME")} to the request. It can be a new header property or even a part of user agent.
We tried to put the property inside HTTP Preferences as a part of user agent string, but it passes the parameter as a string
We also set a global property but couldn't find a way to insert it as one of HTTP calls by default.
The only ways we found so far was:
going to soapui setting of each user and add headers to all requests one by one. (problem: what if user imports more wsdl/wadl later)
adding a startup script to created projects, so it adds the header by default to everything (problem: users can create new projects any time - please note that each soapui instance is individual)
This requirement can easily be fulfilled by the SoapUI's pro software using the feature called Events.
For example, add the header for each request before submitting the web service / rest service call.
However, you mentioned that free version is being used. Wrote an extension some time ago, which allows us to do the same in the free edition of SoapUI. There is a readme available explaining how to use this. Basically this extension implemented the some of the listeners of SaopUI's API while providing the flexibility to the end users what code should they run(in the form of external file) when the respective event occurs.
Complete the instructions mentioned in the readme.
Then you need to do is write a groovy script(already given below) to implement your requirement i.e., add the header to the request. That needs to be done in a file with specific file name located in specific directory(details available there).
In your case, the required code(mostly working sample below) should go into file called RequestStepBeforeSubmit.groovy, in order add the user name into each request's header automatically.
Below code snippet should work even if you use the pro software for the same requirement when SubmitListener.beforeSubmit event happens.
//change the condition if required, should be working for soap/rest types
if (context.getProperty("wsdlRequest")){
def request = context.getProperty("wsdlRequest").testStep.httpRequest
def existingHeaders = request.requestHeaders
def username = System.getProperty('user.name')
existingHeaders['user'] = [(username)]
request.requestHeaders = existingHeaders
}
Related
I am in the process of migrating from Manifest V2 to V3, from Web Request API to Declarative Net Request API. Using Web Request, I modify the "content-security-policy" header by adding a domain into the list of various directives (default-src, frame-src, etc). I tried using the "append" operation in the rule action. Is it possible to target a directive? What if the directive does not exist? Does append just add the supplied string to the end? With Web Request, I was able to examine each directive and update each accordingly, before returning the new value. This allowed me to inject a script that is needed into each frame.
Instead, would it be possible to continue to use the Web Request API with V3? In my setup, I have my chrome extension "Published - unlisted". I do use the force install option when deploying the extension to our internal users, and the only reason I have it unlisted and not private is so that the users who have the extension can get updated whenever a new version is released. Would it be possible to have users updated without having the extension listed? Perhaps by hosting the extension in my own server? Please advise on what can be done to have the ability to update the response header, specifically the "content-security-policy" header the way I have done before, and whether I can continue to use Web Request API going forward (using V3). In the Chrome dev website, there's a mention about continuing to use Web Request if force install is used, and only if its "deployed to a given domain or to trusted testers", but I'm not sure what that actually means. What would I need to do to meet the criteria?
I tried using the append operation in the rule action via the Declarative Net Request API, but its not working as expected. I dont see the security policy being updated when I inspect the response header in dev tools. I also get errors stating that many scripts, images, etc violate the security policy for websites that did not have one to begin with (My extension targets any website).
I am running a simple suitelet with a form, to which I am adding a clientscript.
form.clientScriptModulePath = './clientScript.js';
It works fine, as long as the suitlet is run from the 'normal' url.
But if External URL is used, clientScript seems to be completely ignored, no error, just ignored.
Are Client Scripts not available for External URL's in NetSuite? Or is there some workaround for it?
I didn't find any documentations for External URL restrictions.
When you select Available Without Login and then save the Script Deployment record, an External URL
field is displayed on the Script Deployment page (see following figure). Use this URL for Suitelets you want
to make available to users who do not have an active NetSuite session.
Note The Website feature must be enabled for Clients Scripts to work in externally available Suitelets
Please go to Set up > company > Enable features >Web presence > Website.
Here is a screenshot for your reference
The Suitelet should be in released status to avoid any other errors.
The following table shows how you can specify the localization context based on the script type.
Script Type
Defining Localization Context Filtering
SuiteScript 2.0 Client Script Type
Complete the following steps to add localization context filtering to client scripts:1. Use the localizationContextEnter and localizationContextExit entry points in your script.
Please let me know how this goes!! Happy coding :)
It's been a while but I think your clientScriptModule path needs to be absolute for it to work externally. I think I ran into this a couple of years ago and that turned out to be the solution.
I'm trying to use the auth0-chrome package to authenticate my users. I've followed their "Using the Library" section (set up a new native type application in my tenant and configured the Allowed Callback URLs and Allowed Origins). When emitting my authenticate event to my background script and calling the authenticate() method on the new Auth0Chrome instance, I get the error
Authorization page could not be loaded
My current theory is that since the allowed origin's format in the example is https://<extension-id>.chromiumapps.org and I can't currently access that page. Is there a certain visibility level for a Chrome extension to have a valid URL (e.g. atm for a privately published extension, the *.chromiumapp.org URL is invalid).
I thought a code example is not needed, since I'm literally using the default example's code with my extension ID replaced.
I have double checked and my ID is the same for the auth0 application config, my unpacked extension in my browser and for the configured code. I'm using a manifest key to persist the extension ID if that's of any value.
So turns out the documentation lists the callback url example as https://<yourchromeappid>.chromiumapps.org/auth0, but it should be https://<yourchromeappid>.chromiumapp.org/auth0 - without the s at the end of chromiumapp.
That was the only change required to making it work. I've proposed an update for their documentation as well.
i want to add my project's endpoint in the project tear down script. What is the syntax in order to get the endpoint for all requests and test requests as the user will assign their endpoint via all requests and test requests before running the project?
i seen an example using test step but i don't want to retrieve it via the test step route:
testRunner.testCase.getTestStepByName("dd").getHttpRequest().getEndpoint();
The tear down script use either , log, context, runner nd project variables.
Thanks
Based on the information updated in the question, it looks like you have to access the endpoint in the TearDown Script of the project.
It also appears that you would need to execute the same set of tests against different base url of the endpoint and domain. Not sure even you might need to use the credentials accordingly.
Considering the above, it would be easy to project level properties.
Here you would go:
Create a project level custom property for base url, say BASE_URL as property name and value as http://10.0.0.1:8008. Of course, change it with actual value as needed with respect to the tests to be executed.
Similarly create another project level property for domain, say DOMAIN_NAME and provide its value according the test.
Double click on service / interface, click on Service Endpoints tab.
Remove all the existing values.
Add a new endpoint by clicking + icon.
Add ${#Project#BASE_URL} as endpoint and ${#Project#DOMAIN_NAME} as domain values
If required, you use the same approach for the credentials.
Now click on Assign button there and choose All requests and Tests option from the dropdown.
Similarly, do the same if you have multiple services / interfaces.
How to access the above values in TearDown Script?
log.info "Endpoint : ${project.getPropertyValue('BASE_URL')}"
log.info "Domain : ${project.getPropertyValue('DOMAIN_NAME')}"
When you want to change domain or base url, just change the values of the respective project properties before you run execute the tests against different servers / environments.
EDIT:
The values for the endpoint or domain can passed dynamically (without even changing value saved in the project) from command line using SOAPUI_HOME/bin/testrunner utility while executing the tests. For more details, refer documentation
How do I correctly handle the login/authentication scenario for an Azure web app in my VS2015 web performance test?
I created an XML file as a data source for the WAAD username and password. I bind the username and password to the Form Post Parameters: login and passwd respectively at request: https://login.microsoftonline.com/xxxx/login
But when I run the test, the Web Browser tab shows this error:
We can't sign you in
Your browser is currently set to block JavaScript. You need to allow
JavaScript to use this service.
To learn how to allow JavaScript or to find out whether your browser
supports JavaScript, check the online help in your web browser.
I also get a number of errors like this:
The value of the ExpectedResponseUrl property
Validation xxxx.azurewebsites.net/xxxx/docs/xxxx.aspx does
not equal the actual response URL
login.microsoftonline.com/xxxx/wsfed. QueryString
parameters were ignored.
Any idea how I can successfully log in to the Azure web app via the web performance test?
There are several methods of login and authentication that can be used. Just binding values to form post parameters may not be sufficient or correct. You will find the login form has hidden session identities that must be passed as well as the login data. I find that recording a test two times using as nearly as possible the same inputs and doing the same activities helps. These two tests can then be compared to find the dynamic data that needs to be handled.
In a comment the questioner added "I noticed these parameters, n1-43 are different but I have no idea what they represent. How do I handle them?". I can have no idea what they represent as I do not know the website you are testing. You could ask the website developers. Or, better, treat them as dynamic data. Find where the values come from, save them into context variables and use them as needed. This is basic web test development. Here and here are two good articles on what to do.
The message about JavaScript not being supported can be ignored. Visual Studio web tests do not support JavaScript or any other "active" parts of a web page, they only support the html part. Your job as a tester is to simulate what the JavaScript does for the specific user journeys you are testing. That simulation is generally just filling in the correct values (via context parameters) in the recorded requests.
Unexpected response urls can be due to earlier failures, such as teh login not working. I suggest not worrying about them until all of the other test problems are solved. Then, if you need help ask another new question.