I'm new to Karate and automation and asking for your advice on how to resolve my problem.
I'm running my Karate tests in HTTPS URL but I'm getting the error org/apache/http/conn/ssl/TrustAllStrategy
Anybody has encountered this error before? How did you resolve this?
This occurs after putting * configure ssl = true in my feature file
My karate-config.js looks like this:
function fn() {
var config = {
urlBase: 'https://<our url here>'
}
//karate.configure('ssl', true);
karate.configure('connectTimeout', 10000);
karate.configure('readTimeout', 10000);
return config;
}
My feature file looks like this:
Feature: View Check History
Background:
* configure ssl = true
* url urlBase
You most certainly have a library conflict, my guess is you have mixed Karate into an old project that already uses the Apache HTTP client. You have to resolve this yourself. My suggestion is try the quickstart here, which will work - and then you can compare with what's going on in your project: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
Take the help of someone who knows Maven if needed. All the best.
Related
I am facing weird issue for pact testing. When I use local pact-broker same test is passing however, when I use remote pact-broker test is failing.
systemProperty 'pactbroker.url', 'https://pact-broker.internal-dev.com/' // Test is failing
systemProperty 'pactbroker.url', 'http://localhost:9292/' // Test is passing, I have setup locally and published to it
Errors:
No Pact files were found to verify
Provider: Provider1
Source: Pact Broker https://pact-broker.internal-dev.com/
au.com.dius.pact.provider.junitsupport.loader.NoPactsFoundException: No Pact files were found to verify
Provider: Provider1
Source: Pact Broker https://pact-broker.internal-dev.com/
at au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.provideTestTemplateInvocationContexts(PactJUnit5VerificationProvider.kt:49)
at au.com.dius.pact.provider.spring.junit5.PactVerificationSpringProvider.provideTestTemplateInvocationContexts(PactVerificationSpringProvider.kt:24)
at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$0(TestTemplateTestDescriptor.java:102) and more
Any idea?
Note: This is happening to only one service. For all other services, same setup is working fine and even this is working fine in local broker host. I tried to debug and tests is coming empty.
// Exception point tests.first is empty which should not be. It is not empty when I use Provider2 which for different service.
override fun provideTestTemplateInvocationContexts(context: ExtensionContext): Stream<TestTemplateInvocationContext> {
logger.trace { "provideTestTemplateInvocationContexts called" }
val tests = resolvePactSources(context)
return when {
tests.first.isNotEmpty() -> tests.first.stream() as Stream<TestTemplateInvocationContext>
AnnotationSupport.isAnnotated(context.requiredTestClass, IgnoreNoPactsToVerify::class.java) ->
listOf(DummyTestTemplate).stream() as Stream<TestTemplateInvocationContext>
else -> throw NoPactsFoundException("No Pact files were found to verify\n${tests.second}")
}
}
When I used the provider Provider2(this is for other service) instead of Provider1(I need this), looks like pact is getting resolved and failing for not matching tests, this verifies everything is good in case of setup. I guess somehow it is versioning issue but not sure why passing in local. I tried to rename the provider in publisher side and use it with new name, still same issue.
Pacts on server:
We've deployed a Laravel 5.4 app on AWS (Elastic Beanstalk) with a middleware installed, namely: laravel-ssl-protocol (by resino), which is to force SSL. We've included it on the Kernel.php
protected $middleware = [
...
\Riseno\SSLProtocol\SSLMiddleware::class,
];
It works perfectly on the Homestead/local machine. But it doesn't work on the server (AWS ELB). I attached the actual image or the problem.
firefox and chrome too many redirect
Any idea on how to resolve this issue would be much appreciated. Thanks.
I finally found the fix of my problem and I think I need to share it here. So if somebody with the same problem that I had, this might help them. As I did some research on the web I found this article: How to Configure Symfony to Work behind a Load Balancer or a Reverse Proxy . And did some minor change on the current middleware, laravel-ssl-protocol (by resino) as follows:
public function handle($request, Closure $next)
{
$request->setTrustedProxies([$request->getClientIp()], Request::HEADER_X_FORWARDED_AWS_ELB);
if (!$request->secure() && env('APP_ENV') === 'production') {
return redirect()->secure($request->path());
}
return $next($request);
}
And uploaded the updated codebase to AWS and tada! It works. The 302 error was gone for good. The key was "Request::HEADER_X_FORWARDED_AWS_ELB".
I trying to setup RestComm Web SDK demo application on my local system, I just want to create an application for audio/video, chat, IVR, etc(RestComm provide me perfect solution for my needs). Now I have setup RestComm Web SDK on my local system and whenever I an trying to sip call, It throws WebRTCommClient:call(): catched exception:NotSupportedError: Failed to construct 'RTCPeerConnection': Unsatisfiable constraint IceTransports on browser console.
My webRTC confrigration is as below:
// setup WebRTClient
wrtcConfiguration = {
communicationMode: WebRTCommClient.prototype.SIP,
sip: {
sipUserAgent: 'TelScale RestComm Web Client 1.0.0 BETA4',
sipRegisterMode: register,
sipOutboundProxy: parameters['registrar'],
sipDomain: parameters['domain'],
sipDisplayName: parameters['username'],
sipUserName: parameters['username'],
sipLogin: parameters['username'],
sipPassword: parameters['password'],
},
RTCPeerConnection: {
iceServers: undefined,
stunServer: 'stun.l.google.com:19302',
turnServer: undefined,
turnLogin: undefined,
turnPassword: undefined,
}
};
While I can use olympus without any issue in Chrome Browser. I am stuck with this exception, any suggestions would be highly appreciated.
I think the problem here is that the version of Webrtcomm library inside the demo application you are using is outdated and doesn't include a fix for latest Chrome version. So please replace samples/hello-world/scripts/WebRTComm.js within your repository, with:
https://github.com/RestComm/webrtcomm/blob/master/build/WebRTComm.js
That should fix your issue.
Best regards,
Antonis Tsakiridis
I have followed Spring Boot setup and can easily get Tomcat to run with SSL, however I'd like to use Jetty and there is little documentation out there for this. I can get access to the JettyEmbeddedServletContainerFactory, but it doesn't use the same interface methods to gain access to the configuation.
Has anyone had any luck configuring jetty 9 inside spring boot to use SSL? I found a similar question here and wondered if there was anyone that solved this.
Any help would be great.
So there was a recent question posted to Spring Boot (day of or before I asked here, nice timing) via GitHub that asked for support for the same. They have an example of this working, and an example of how this will work after the new commit they will/have made. I'm using the former, and it's working fine. Looks like you can either get the latest source or wait for another release/milestone.
Here is a link to the discussion.
Here is my solution, but it works just as they say in their answer. I have not pulled their commit, so I'm using the first solution with the base Jetty API. Using Jetty 8 with Spring Boot for this sample, but Jetty 9 worked also.
#Bean
public EmbeddedServletContainerFactory embeddedServletContainerFactory() throws Exception {
return new JettyEmbeddedServletContainerFactory() {
#Override
protected JettyEmbeddedServletContainer getJettyEmbeddedServletContainer(
Server server) {
SslContextFactory sslContextFactory = new SslContextFactory();
sslContextFactory.setKeyStorePath("/usr/local/keystore");
sslContextFactory.setKeyStorePassword("password");
sslContextFactory.setCertAlias("alias");
SslSocketConnector sslConnector = new SslSocketConnector(sslContextFactory);
sslConnector.setPort(8443);
server.setConnectors(new Connector[] { sslConnector });
return super.getJettyEmbeddedServletContainer(server);
}
};
}
Are you using maven as build system? If so, you could check this pom.xml artifact - http://bghints.blogspot.com/2012/03/client-authentication-with-ssl_28.html
The blog post is for jetty 6. For jetty 9, there is a difference. Group ID must change from:
org.mortbay.jetty
to
org.eclipse.jetty
I hope this helps you.
I am using scribe 1.3.0 for OATH authentication. This is on Tomcat 7 under Ubuntu.
I am pretty sure this is some sort of a pilot error but cannot figure out what is wrong exactly...
I create the service and token in the constructor of my client class:
public Client()
{
m_service = new ServiceBuilder()
.provider(Api.class)
.apiKey(CONSUMER_KEY)
.apiSecret(CONSUMER_SECRET)
.debug()
.build();
m_accessToken = new Token(OAUTH_TOKEN, OAUTH_TOKEN_SECRET);
}
Later on when time comes to make a request I use the service in a function:
OAuthRequest request = new OAuthRequest(Verb.GET,
url);
m_service.signRequest(m_accessToken, request);
Since I added the debug() tag to the ServiceBuilder I get the following output:
signing request: URL
setting token to: Token[xxxx , xxxxx]
generating signature...
thats it.. nothing else happens, the code just seems to die there.
I tried to catch Exception from the m_service call but it does not throw exception.
I had tried this code before on a different Windows machine with Jetty and it worked but I dont have access to that machine or OS anymore..
What could I be doing wrong? Is there anything else I can do to get more debug output?
-Wish
Turns out that I needed to include the apache codec jar files in Tomcat.
I did go back to try my app on Jetty again under Windows, that worked without the codec. I am not entirely sure why linux+Tomcat needs apache codec while Jetty+Windows7 does not..
If I had Maven would not have this issue..