Karate-gatling: set local addresses - karate

I have simple karate feature file for testing an API, and I want to use this feature file for load testing. Thus I am using Gatling to execute the karate feature file: https://github.com/intuit/karate/tree/master/karate-gatling
However, when I fire up multiple users, I want to submit the requests with different ip alias that I have configured.
Using Gatling, I could use localAddress to bind to the socket
val protocol = http.localAddresses(ip)
But in Karate-Gatling, karateProtocol is used instead
val protocol = karateProtocol()
And the readme states that "Karate is responsible for making HTTP requests while Gatling is only measuring the timings and managing threads".
This means that the HTTP requests and localAddress bindings cannot be changed through Gatling, but I am wondering if there is a workaround through Karate so that different ip alias can be used for different requests.

This sounds like a feature request is needed to tell the HTTP client (Apache for e.g.) to use a local-address.
It would be great if you can help contribute and test, one way to set the localAddress would be in the code here:
RequestConfig.Builder configBuilder = RequestConfig.custom()
.setCookieSpec(LenientCookieSpec.KARATE)
.setConnectTimeout(config.getConnectTimeout())
.setSocketTimeout(config.getReadTimeout());
String localIp = "1.2.3.4";
try {
InetAddress localAddress = InetAddress.getByName(localIp);
configBuilder.setLocalAddress(localAddress);
} catch (Exception e) {
context.logger.error("failed to resolve local address: {}", localIp);
}

Related

Selenium iOS Driver behind Proxy

We are trying to run some automated tests for our Xamarin based iOS app using the Selenium IOSDriver within Visual Studio for Mac.
The error we are getting when we run them is (I've sanitised to remove the URL we are actually trying to send the request to).
A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL https://<Test Host URL>. The status of the exception was NameResolutionFailure, and the message was: nodename nor servname provided, or not known nodename nor servname provided, or not known
Because our machines are behind a proxy we often see DNS errors like this when the code sending the request is unaware of the proxy.
We've tried various approached to setting the proxy, such as HttpClient.DefaultProxy and OpenQA.Selenium.Proxy but the error still persists.
Are there any other ways to tell Selenium that it is operating behind a proxy?
For anyone else struggling with this the answer seemed to be using a 'HttpCommandExecutor'
var uri = new Uri("https://hub.browserstack.com/wd/hub/");
var commandExecutor = new HttpCommandExecutor(uri, TimeSpan.FromSeconds(30))
{
Proxy = new WebProxy
{
Address = new Uri("http://your.proxy")
}
};
driver = new IOSDriver<IOSElement>(commandExecutor, options);

How do I get the server ip/port for a ktor service?

I'm looking to write a Ktor feature that should announce the service on a local network using DNS-SD/mDNS. I would like to be able to automatically start the announcing on ktor application start and stop it on ktor application stopped. I've written code that does this using ApplicationStarted and ApplicationStopped event. This code works.
However, I can find no way of getting what IP address/port from ktor other than reading the configuration.
Is there any way of listening for/listing the connectors that ktor is currently using?
You can access connectors through the BaseApplicationEngine instance:
val server = embeddedServer(Netty, 9091) {}
println(server.environment.connectors)
or by casting environment to ApplicationEngineEnvironment:
fun Application.module(testing: Boolean = false) {
(environment as ApplicationEngineEnvironment).connectors.forEach { connector ->
println("${connector.host}:${connector.port}")
}
}

Is there a way to set JMS to use SSL/TLS connecting to IBM MQ?

We have a Java application that uses JMS to communicate with IBM MQ. A part of their requirement is now to use TLS. Is there a way to do this? The parameters they were expecting to add are:
sslCipherSuite
hostname
port
channel
Is there any system environment property that we can set to JMS for this parameters?
the current code uses
import javax.jms.ConnectionFactory;
and we use to a config file to set system env variables.
environment.setProperty("java.naming.factory.initial", this.config.get("JMS_JndiContextFactory"));
this.setJndiExtraParameters(environment, this.config.get("JMS_JndiExtraParameters"));
while (!this.state.atLeast(State.GOT_FACTORY) && iterator.hasNext()) {
environment.setProperty("java.naming.provider.url", this.urlUsed = iterator.next());
try {
JmsClient.LOGGER.debug("Looking up connection factory");
this.factory = (ConnectionFactory)new InitialContext(environment).lookup(this.config.get("JMS_FactoryName"));
this.state = State.GOT_FACTORY;
}
im thinking if there is a way to set only another set of system properties instead of using
MQConnectionFactory
so we don't have to change something in the code?
i posted a similar question , reposted it because of lack of clarity

MobileFirst JavaScript adapter load local config file

I am creating multiple applications which works the same. For every application I use an adapter which contains the same procedures, but perform the request to a different back end (same host, only different path).
The thing I would like is to add a configuration file (json / xml) to the adapters which I can load and fetch some information from such as the path so I know which back end I need to call. The configuration is now in top of the file, but in the future it would be lovely to be able to update the adapter without changing the configuration afterwards.
Is there a way to load a second file located in the same directory (as where the adapter xml and implementation file are)? I tried using XMLHttpRequest, but this doesn't work as it is unavailable. The code I tried, but couldn't test as the fifth line already breaks.
var config = null;
function loadConfiguration() {
var loader = new XMLHttpRequest();
loader.overrideMimeType('application/json');
loader.open('GET', 'config.json', false);
loader.onreadystatechange = function () {
// Only for async calls.
config = loader.responseText;
};
config = loader.send();
}
If there is a better way, I would love to hear it! We upgraded to MFPF 7.0 if there are any new possibilities.
You cannot do this with JavaScript adapters, however in MFPF 7.0 there is a new type of adapters: Java adapters. Using Java adapters you can achieve this.
The following blog post explains how you can provide a single adapter that will allow you to point to different hosts or differents paths in the same host, etc...
See here: Changing the adapter host at runtime

How to manually set/propagate security context information e.g. Principal for JBoss 7 (over JBoss remoting 2)

I'm using jboss remoting 2.5.4.SP3 to provide remote access to EJBs in a JBoss 7.1 server from both a web app and other JBoss instances. I'm doing it manually because of issues with remote EJB access in JBoss 7.1, specifically (but not only) the inability to access the same (interface) bean on multiple servers simultaneously. I'm using remoting2 because remoting3 has no documentation.
I have remoting working using TransporterHandle/TransporterClient using the socket transport, but in methods called via this remote connection, the server wants to lookup the principal from the ejbContext. I can't find a way to manually set the principal, or other contextual security/identity information. At the limit I'd be happy just to set the principal when the ejb method is invoked - all incoming calls are to local EJB3 beans - or even to set it specifically for the EJBContext.
I've found a lot of information regarding Spring (which I'm not using), but nothing seems to match my particular context.
And now, the correct way to do this:
On the client side I get the security context and package up the security domain and subject info for transport to the server along with the invocation. The SecurityDomain is a String and SubjectInfo is serializable:
Map m = new HashMap();
SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
if (securityContext != null) {
m.put("SUBJECT-INFO", securityContext.getSubjectInfo());
m.put("SECURITY-DOMAIN", securityContext.getSecurityDomain());
}
response = remotingClient.invoke(request, m);
The map m gets sent with the invocation over jboss remoting. On the server side, I extract the security information and set the context for the invocation like this:
SecurityContext oldContext = SecurityContextAssociation.getSecurityContext();
SubjectInfo si = (SubjectInfo) invocation.getRequestPayload().get("SUBJECT-INFO");
String domain = (String) invocation.getRequestPayload().get("SECURITY-DOMAIN");
if (si != null) {
SecurityContext sc = new JBossSecurityContext(domain);
sc.setSubjectInfo(si);
SecurityContextAssociation.setSecurityContext(sc);
}
try {
return super.invoke(invocation);
} finally {
SecurityContextAssociation.setSecurityContext(oldContext);
}
Works like a charm!
Have a look at the jboss-ejb-client.properties. There is also a quickstart example using a remote client to lookup an EJB.
I've solved my underlying problem, although not in the general way I was hoping for.
I put a servlet filter on all incoming requests, recording request.getUserPrincipal in a thread local. I can then access this in non-EE code and find the principal making the request. Then when I make call to my app server I use JBoss Remoting's ability to attach metadata to each invocation to pass the Principal over the wire. I had to copy the TransporterClient to do this because it's private constructors et al don't allow for overriding the functionality required to attach per-request metadata (as opposed to per-connection). On the server side I take the incoming Principal and set it into a thread local. Then, in subsequent code that accesses EJBContext.getCallerPrincipal I also lookup the incoming Principal from the thread local, and if that isn't null (hence we are in a remote EJB call), I use that if the caller principal is anonymous. If it's not anonymous then it must have been set in some way after the incoming call, so I ignore the incoming Principal in that case.
All in all, a much more specialised solution than I was hoping for, and it doesn't shed any light on how I can do generic context propagation in JBoss 7.1 over the wire.