I am trying to test an REST API on my local machine using frisby.js . It throws the following error.
Error: tunneling socket could not be established.
The machine address is something like 'https://machine_name:8443'
It seems that you are behind a proxy. Then, to make your frisby test working, you need to apply proxy configuration as follows:
var frisby = require('frisby');
frisby.globalSetup({
request: {
proxy: 'http://xx.xx.xx.xx:yyyy' // Provide proxy info (host, port) here
}
});
frisby.create('Your spec description here')
.get('https://machine_name:8443')
.expectStatus(200)
.toss();
Note also that you are using HTTPS protocol. Then you may find useful my answer in this post in case you have problems with SSL certificates
Related
I configured an HTTPS website on AWS, which allows visiting from a white list of IPs.
My local machine runs with a VPN connection, which is in the white list.
I could visit the website from web browser or by the java.net.http package with the below code:
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://mywebsite/route"))
.GET() // GET is default
.build();
HttpResponse<Void> response = client.send(request,
HttpResponse.BodyHandlers.discarding());
But if I replaced the code with a Vertx implementation from io.vertx.ext.web.client package, I got a 403 forbidden response from the same website.
WebClientOptions options = new WebClientOptions().setTryUseCompression(true).setTrustAll(true);
HttpRequest<Buffer> request = WebClient.create(vertx, options)
.getAbs("https://mywebsite/route")
.ssl(true).putHeaders(headers);
request.send(asyncResult -> {
if (asyncResult.succeeded()) {
HttpResponse response = asyncResult.result();
}
});
Does anyone have an idea why the Vertx implementation is rejected?
Finally got the root cause. I started a local server that accepts the testing request and forwards it to the server on AWS. The testing client sent the request to localhost and thus "Host=localhost:8080/..." is in the request header. In the Vert.X implementation, a new header entry "Host=localhost:443/..." is wrongly put into the request headers. I haven't debug the Vert.X implementation so I have no idea why it behaviors as this. But then the AWS firewall rejected the request with a rule that a request could not come from localhost.
I want to make 2 devices communicate via sockets.
I use this code for the client socket:
Socket socket = Gdx.net.newClientSocket(Net.Protocol.TCP, adress, 1337, socketHints);
(SocketHints: timeout = 4000)
I get a GdxRuntimeException each time this line is being executed. What is wrong with the socket?
Screenshot of stack trace
You get that message because the socket couldn't be opened.
Note the last line about the return in the API:
newClientSocket:
Socket newClientSocket(Net.Protocol protocol,
java.lang.String host,
int port,
SocketHints hints)
Creates a new TCP client socket that connects to the given host and port.
Parameters:
host - the host address
port - the port
hints - additional SocketHints used to create the socket. Input null to use the default setting provided by the system.
Returns:
GdxRuntimeException in case the socket couldn't be opened
Try doing some debugging to find out why you are getting this error.
Is the port already in use? Are you trying to open more than one connection on the same port? Is the server IP valid? Maybe something else is causing the issue?
I am writing a NodeJS application which is supposed to get deploymentstatuses from the Kubernetes API using the websocket transport layer.
For this I use the socket.io-client module and I connect with the following snippet:
var url = 'wss://myurl:8443?watch=true&access_token=myaccesstoken';
var socket = ioClient.connect(url, {
reconnect: true,
transports : ['websocket'],
path : "/api/v1/namespaces/mynamespace/replicationcontrollers",
secure : true,
rejectUnauthorized: false,
verify : false});
This however gives me an unexpected error, 403. Testing this in extensions like Websocket Client to Chrome works perfectly fine. Also I receive a 200 if I try a path with less sensetive data, but not an upgrade to websocket.
I read somewhere the Kubernetes API doesn't treat the WebSocket-protocol correctly, perhaps this is related? I have also tried with other more native libraries to Node such as websocket and ws with the same result.
When adding a ?watch=true in a Kubernetes API call, the request does not use WebSocket's but instead will stream / chunk the response over the HTTP connection.
Here is my smack code to connect ejabberd server
XMPPTCPConnectionConfiguration.Builder builder = XMPPTCPConnectionConfiguration.builder();
builder.setUsernameAndPassword("admin#manish-lenovo-g510", "admin");
builder.setServiceName("manish-lenovo-g510");
builder.setHost("192.168.1.2");
builder.setPort(5280);
XMPPTCPConnectionConfiguration build = builder.build();
AbstractXMPPConnection conn1 = new XMPPTCPConnection(build);
conn1.connect();
I am getting this error:
Exception in thread "main" org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 5000ms (~5s). Used filter: No filter used or filter was 'null'.
at org.jivesoftware.smack.SmackException$NoResponseException.newWith(SmackException.java:106)
at org.jivesoftware.smack.SmackException$NoResponseException.newWith(SmackException.java:85)
at org.jivesoftware.smack.SynchronizationPoint.checkForResponse(SynchronizationPoint.java:253)
at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWait(SynchronizationPoint.java:146)
at org.jivesoftware.smack.SynchronizationPoint.checkIfSuccessOrWaitOrThrow(SynchronizationPoint.java:125)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:837)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:365)
if i open admin interface of ejabberd its opening so Why this code is not working. One more thing how to find the service name as i guess that might be the issue as i dont know the service name, i have given it randomly.
I think port should be the standard XMPP port which is 5222. 5280 is the port for web admin, which speaks HTTP, not XMPP.
Fiddler Error Connecting to HTTPS Applications
Fiddler Log:
!SecureClientPipeDirect failed: Authentication failed because the remote party has closed the transport stream. on pipe to (CN=services.bigpond.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
I have followed other posts but no answers
The typical explanation for this message, as documented in many places, is that the client application has not been configured to trust Fiddler's root certificate. As such, the client closes the connection to Fiddler when it sees the untrusted certificate.
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/TrustFiddlerRootCert
In Kestrel I'm using an SSL cert.
I 'downgraded' the TLS protocol in order to get this to work.
This is not something you'd do in production - but in production you shouldn't be using kestrel. I'm not saying this is the best overall config, but this is mainly to show the SslProtocols option.
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options =>
{
options.Listen(IPAddress.Any, 5000); // http:localhost:5000
options.Listen(IPAddress.Any, 44300, listenOptions =>
{
// https://dotnetthoughts.net/enable-http2-on-kestrel/
//listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http2;
listenOptions.UseHttps(#"S:\WORK\SSL\example.com.pfx", "cert-password", httpsOptions =>
{
httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls;
});
});
})
.UseStartup<Startup>();