Hi there I am trying to communicate two aplications (both APIs) in the same cluster on kubernetes(from openshift) but in a different namespace...
When I send the httpclient request using regular URL I get a SSL error because the route "leaves" the internal network and "comes back". With a advice I changed the comunication using my service name (mapped on the pods)... Now I don't get the error but the HTTRESPONSE I gete is Null, with no error or statuscode:
Here is how I configured the service name:
http://servicename.projectname.svc.cluster.local:8080/
If i change the port to 8080 or use http I get the error "no route to host" but the route is set. But the HOST field below is set to the URL and not the cluster host, could the problem be this?
Solved by setting the certificate in the pipeline (yaml) so it is applied in the pods
Related
I've been using a Self-Hosted SignalR Windows service accessed from multiple production servers (now in Azure) for 6+ years without a problem. I created an identical server for development in Azure but when I'm accessing SignalR from a browser on the SAME SERVER, SignalR gives me the following error when using either http:6287 or https:6286:
Access to XMLHttpRequest at 'http://myserver.learn.net:6287/signalr/negotiate?clientProtocol=1.5&xxxxxxx' from origin 'http://myserver.learn.net' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
However... It WORKS when connecting from OTHER SERVERS! I'm starting the connection with no errors using:
SignalR = WebApp.Start("http://myserver.learn.net:6287/");
SignalRSSL = WebApp.Start("https://myserver.learn.net:6286/");
(also SignalR = WebApp.Start("*:628x/" for both);
In my client code, I include the following script:
<script src="http://myserver.learn.net:6287/signalr/hubs"></script>
When I enter that url (or https version) in a browser ON THE SAME OR DIFFERENT SERVER, it shows the ASP.NET SignalR JavaScript Library v2.3.0-rtm page correctly! I've turned off the firewall with no change, added Microsoft.Owin.Host.HttpListener (someone suggested). I have also entered the wildcard certificate with netsh so the SignalR service can deal with the SSL connection using:
netsh http add sslcert ipport=0.0.0.0:6286 appid={12345678-db90-4b66-8b01-88f7af2e36bf} certhash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Edit: I've also tried changing the ipport value to the real internal IP of the server as well as the public IP but no change.
So, why can't I access SignalR from the same server?
I found a solution in another answer here that worked. I changed:
$j.connection.hub.start().done(function () {
To:
$j.connection.hub.start({ jsonp: true, xdomain: true }).done(function () {
Which worked for both internal and external clients. xdomain:true alone didn't work but when I added jsonp:true it did. I have no real idea why, just that it's working now.
I have my .net core api that wants to access a service which is hosted on another server. My current working connection string is:
"AuthorityUrl": "https://identity.test.company.eu/"
The https://identity.test.company.eu is a website listening on a Server whose address is 192.168.41.2 . This website is hosted on IIS and listening to all unassigned ip with hostname in the bindings set to identity.test.company.eu . This means that IIS redirects the call towards this specific website. How does it do it? It reads that the incoming http call has hostname header equals to identity.test.company.eu and therefore is able to route the call.
Now, let's say that I don't have access to the DNS mapping and that I have to set manually in my connection string that I want to send a request to the 192.168.41.2 server and include in the call the hostname header identity.test.company.eu . In such a way IIS on the server redirects the call towards the right website. How can I do this?
Thansk!
I am new to docker containers and Im running into the following issue. I am developing a web page that makes requests to an exposed api. Both of them are published on different containers that are linked through a network.
This is my docker-compose.yml file:
version: '2'
services:
api:
image: my/api
networks:
- api
ports:
- "8080:5000"
container_name: api
web:
build:
context: ./DockerWeb
networks:
- api
ports:
- "80:5000"
container_name: web
networks:
api:
driver: bridge
I have noticed that if I attach to the container running my webpage I can ping the api container without any issue using ping api
The issue comes when trying to make any web service call to the api container. I am trying to initialize an HttpClient object, however the BaseAddress property of such an object must be set to a valid Uri.
_client = new HttpClient();
_client.BaseAddress = new Uri(config.ApiUrl); //config.ApiUrl = "api"
This throws the following error
UriFormatException: Invalid URI: The format of the URI could not be determined.
Is there a way to either a) Expose the container name in a different way, or b) make a call to a web service without the need of using a URI?
How can I accomplish this?
UPDATE
I have updated the ApiUrl to contain the value http:api:8080, however now I am getting an exception when performing the call
System.AggregateException: One or more errors occurred. (An error occurred while sending the request.) ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.Http.CurlException: Couldn't connect to server
I have also tried the calling the api endpoint directly from my web container using wget
wget http://api:8080/
However I still receive back an error:
Connecting to api (api)|172.24.0.4|:8080... failed: Connection refused
Could this be an API configuration error?
api is just the hostname. The URI would be http://api:8080 (or https://api:someotherport if you set up SSL/TLS.)
The internal port is used for connections inside the docker network. So in this case it is the request needs to go to http://api:5000
Here there is 2 kinds of communication:
Container web > Container api
In this case, indeed, you can just use the hostname "api" to connect to your api.
This is what you would have to do if your html is generated server side.
Web Client > Container api
Here however I suppose that you are using some kind of JavaScript web application (Angular or other). In that case the html (and the call) is not made from the web container but directly from your web browser.
So in that case you have to use http://localhost:8080 (I suppose that Docker is running on your local machine).
I hope it helps
Quick version
I'm sure many people have implemented a [RequireHttps] SSL check of some description (message handler, attribute, whatever) at some point in their Web API development. How do you guys and gals test that it works correctly both in terms of success and failure?
Not so quick version
I'm developing a REST service in a OWIN self-hosted ASP.NET Web API 2. I have already successfully secured the service with SSL and have implemented a custom [RequireHttps] attribute (derived from the answers to this SO question).
In the case when the client is calling the correct URL (e.g. https://my.server.com/api/values), if I add a breakpoint in the attribute definition, the debugger correctly breaks in the code (just calls the base and all is well, as expected).
The question is: how can I exercise the failure scenario for this attribute, such that the attribute code will return an error response without interfering with other server processes?
My Web API service listens on base address https://+:9443/. I've tried removing the s such that I connect to http://my.server.com:9443/api/values, but I get an error response status 502 (connection failed) after about a minute's timeout. Fair enough I suppose, but I was actually hoping to return a response ("SSL required") from my [RequireHttps] attribute.
Then I've tried creating the following StartOptions object:
var options = new StartOptions();
options.Urls.Add("https://+:9443/"); // listen on port 9443 with SSL
options.Urls.Add("http://+:80/"); // listen to standard HTTP port 80
and passing it to the WebApp like this:
WebApp.Start<Startup>(options)
Again, this didn't work when I connected to http://my.server.com:9443/api/values, but it worked when I connected to http://my.server.com:80/api/values.
However, this is not what I want to do. My production server hosts both secure (HTTPS) and insecure (HTTP on port 80) resources so my code will intercept legitimate calls to other processes that rely on port 80 and tell them to reconnect via https, which is wrong.
Can someone please advise on what options I have? Is there even a point to have [RequireHttps] given my situation, as it never seems to do anything useful?
What you are trying to do can't be done. Basically, you're trying to do the same thing as typing
http:443//www.google.com
Notice how that doesn't work either
The problem is that you're trying to access an http protocol over an SSL protocol port, and that is what's failing. Your code for the RequireHttps doesn't even get to execute because the request can't even be processed through IIS.
I've got a siluation where i need to access a SOAP web service with WSE 2.0 security. I've got all the generated c# proxies (which are derived from Microsoft.Web.Services2.WebServicesClientProtocol), i'm applying the certificate but when i call a method i get an error:
System.Net.WebException : The request failed with HTTP status 405: Method Not Allowed.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
I've done some googling and it appears that this is a server configuration issue.
However this web service is used many clients without any problem (the web service is provided by a Telecom New Zealand, so it's bound to be configured correctly. I believe it's written in Java)
Can anyone shed some light on this issue?
Ok, found what the problem was. I was trying to call a .wsdl url instead of .asmx url.
Doh!
I found this was due to WCF not being installed on IIS. The main thing is that the .svc extension has to be mapped in IIS See MSDN here. Use the ServiceModelReg tool to complete the installation. You'll always want to verify that WCF is installed and .svc is mapped in IIS anytime you get a new machine or reinstall IIS.
I had the same problem, but the details were different:
The Url we were using didn't have the file (.asmx) part. Calling the Url in a browser was OK. It also worked in a simple client setting the URL through Visual Studio.
But it didn't worked setting the Url dynamically! It gave the same 405 error.
Finally we found that adding the file part to the Web Service Url solved the problem.
Maybe a .Net framework bug?
You needto enable HTTP Activation
Go to Control Panel > Windows Features > .NET Framework 4.5 Advanced Services > WCF Services > HTTP Activation
hmm are those other clients also using C#/.NET?
Method not allowed --> could this be a REST service, instead of a SOAP web service?
MethodNotAllowedEquivalent to HTTP status 405. MethodNotAllowed indicates that the request method (POST or GET) is not allowed on the requested resource.
The problem is in your enpoint uri is not full or correct addres to wcf - .scv
Check your proxy.enpoint or wcf client.enpoint uri is correct.
In my case the problem was that the app config was incorrectly formed/called:
in config the service url was using "localhost" as domain name, but real hostname differed from the URL I called :( so I changed the "localhost" in config to domainname thah I use in URL. That`s all!