Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

| Views: 430
I've written recently about some peculiar behaviour in SoapUI when using Setup Scripts and also about using testrunner.sh and project properties to to run SoapUI tests via the command line. Those articles were informative in their own right but they didn't cover one important part that many web services usually (and should!) have - authentication. So I'm going to tackle that here, or specifically how to make your SoapUI test cases authenticate to a web service.

If you're reading this post you probably have come across this error when using testrunner.sh...
 SOAP Error
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Draft//EN">
<HTML>
<HEAD>
<TITLE>Error 401--Unauthorized</TITLE>
</HEAD>
<BODY bgcolor="white">
<FONT FACE=Helvetica><BR CLEAR=all>
<TABLE border=0 cellspacing=5><TR><TD><BR CLEAR=all>
<FONT FACE="Helvetica" COLOR="black" SIZE="3"><H2>Error 401--Unauthorized</H2>
</FONT></TD></TR>
</TABLE>
<TABLE border=0 width=100% cellpadding=10><TR><TD VALIGN=top WIDTH=100% BGCOLOR=white><FONT FACE="Courier New"><FONT FACE="Helvetica" SIZE="3"><H3>From RFC 2068 <i>Hypertext Transfer Protocol -- HTTP/1.1</i>:</H3>
</FONT><FONT FACE="Helvetica" SIZE="3"><H4>10.4.2 401 Unauthorized</H4>
</FONT><P><FONT FACE="Courier New">The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.</FONT></P>
</FONT></TD></TR>
</TABLE>
</BODY>
</HTML>


That error is simply due to SoapUI not authenticating to WebLogic (or another container) when sending a SOAP request. It's easily fixed, at least in the UI. However, when testing it is a good idea to be able to control what username and credentials are used for authentication, after all you may want to try different combinations of users and credentials that may have varying access rights, etc.

I found this article that talks about how to achieve this effect at the test suite level, but didn't like the implementation since it didn't use project properties to set the HTTP auth.

My version takes a slightly different approach, similar to what I described in my previously article on using SoapUI with project properties. I add a Setup Script to the Test Case. In addition I do a little bit more validation to ensure authentication happens or the test case fails if login details are not provided. For my testing, I only had one test case that was ran multiple times so this approach worked well. The script below can be easily updated to work with a suite if so required.

So first of all you need to open the Test Case Editor and click the Setup Script tab, that's where you add the code for the script.
soapui_auth.png




This is the script I used...
 Groovy
import com.eviware.soapui.impl.wsdl.teststeps.*
def httpUser = testCase.project.getPropertyValue("httpUser")
def httpPasswd = testCase.project.getPropertyValue("httpPasswd")
assert httpUser != null
assert httpPasswd != null
for(testStep in testCase.getTestStepList()) {
if(testStep instanceof WsdlTestRequestStep) {
def headers = testStep.getHttpRequest().getRequestHeaders()
headers.remove("Authorization")
headers.put("Authorization", "Basic " + (httpUser + ":" + httpPasswd).bytes.encodeBase64().toString())
testStep.getHttpRequest().setRequestHeaders(headers)
}
}


What the above script does is look for two project properties, httpUser and httpPasswd, makes sure they aren't null and then creates a HTTP Authorization header using those two properties.

Now to set those properties you pass them using the -P parameters to the testrunner.sh script like so:
 testrunner.sh
testrunner.sh <options> -P httpUser=weblogic -P httpPasswd=MyPassword123


Not showing all the other options that are required for testrunner.sh for brevity.

So that's all there is to it. If you have multiple test cases that require authentication, copy/paste the above script into each of them, but at that point you probably should consider using a test suite setup script instead.

-i

Have comments or feedback on what I wrote? Please share them below! Found this useful? Consider sending me a small tip.
comments powered by Disqus
Other posts you may like...