I want to call webservice from domain A with the C# code in Domain B. I have tried to add web reference with URL of that web service but it gives error like
There was an error downloading 'http://localhost:15666/MailBox/'.
Unable to connect to the remote server
No connection could be made because the target machine actively refused it 127.0.0.1:15666
There was an error downloading 'http://localhost:15666/MailBox/$metadata'.
Unable to connect to the
I am having so many issues because of cross domains. Is there any solution for this?
Since you have requested the web service on localhost, this isn't a cross-domain issue. I suspect that you need to update your reference to point to a web service on a different machine.
Your problem (at least the exception you pasted) has nothing to do with calling web services on another domain. It indicates that your machine (localhost) has port 15666 closed and hence you receive the actively refused it error message. You are either not running your web service on that port or your windows firewall is blocking the connection, although this is very unlikely since firewalls usually accept connections from localhost.
You can always check this sort of thing by telneting to localhost on the particular port you are interested in or by using nmap to scan your own ports.
Hi finally I get answer for my question ,This is not problem with crossdomain but I get problems because I didn't create disco file or WSDL file for my webservice so I get error for metadata.I run my webservice locally get WSDL file from there and create new WSDL file for my WEB SERVICE and boom... problem solved .Thanks for all your help...
You have to create a file (clientaccesspolicy.xml) and put it into the wwwroot directory or the main directory of your webservice.
Content of the file should be like:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
You can read more about that at To use a clientaccesspolicy.xml file to allow cross-domain access
Related
I have a new Web API developed in ASP.NET Core. This Web API is supposed to be deployed in IIS and will have to work over SSL, so I have the [HttpsRequired] attribute on all my controllers. I struggle to make it work while deployed, so for now I relaxed the requirements and commented out those attributes. Doing so, I was able to create two bindings in IIS, one for HTTPS and one for HTTP. Given that my Web API is created in ASP.NET Core, I followed the deployment steps Rick Strahl has in his excellent blog post. I have selected "No Managed Code" for the .NET CLR version. The IIS machine is a 64-bit Windows Server 2012 R2 environment - not sure whether this matters or not. The .NET Core Windows Server Hosting bundle has been installed on the server and I can see the AspNetCoreModule listed in the Modules grid.
If i try to access the Web Api (I created a very simple GET method that returns some information regarding the assembly) with Fiddler, I get a 404 error. For now, i run Fiddler on the same machine, so I tried all combinations (localhost, IP address and full machine name in the domain).
No errors are logged in the EventViewer. Does anyone have any suggestion on how to troubleshoot this issue?
TIA,
Eddie
EDIT1: Here is my controller:
[Route("api/info")]
//[RequireHttps]
public class InfoController : Controller
{
private ITncRepository _repository;
public static ApplicationAssemblyDetails ApplicationAssemblyDetails { get; set; }
public InfoController(ITncRepository repository)
{
_repository = repository;
ApplicationAssemblyDetails = ApplicationAssemblyDetails.Current;
}
[HttpGet("")]
public JsonResult Get()
{
return Json(new WebApiInfoModel()
{
CurrentTime = DateTime.Now,
CurrentUtcTime = DateTime.UtcNow,
AssemblyName = ApplicationAssemblyDetails.ApplicationAssembly.FullName,
VersionNumber = ApplicationAssemblyDetails.VersionNumber,
BinFolder = ApplicationAssemblyDetails.BinFolder,
BuildMode = ApplicationAssemblyDetails.BuildMode,
TradeMark = #" © 2016-2017 * SomeCompany (www.somecompany.com)"
});
}
}
The ApplicationAssemblyDetails is a nuget package that gives some info about the current assembly. WebApiInfoModel is my model class for the Web API Information I want to pass back as a test to the client.
The web.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\My_ASP_NET_Core_Web_API.exe" arguments="" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" />
</system.webServer>
</configuration>
Finally, to answer your last question, Ignas, I use a Publishing Profile that uses the File system as a method, targets the .NET Framework 4.5.2, using the release configuration. Given that my project is a Web API and not an MVC 6 Web Application, the publishing package creates a stand-alone application. Since the clients need to call my Web API using SSL, I think that it has to be hosted in IIS, so running the standalone application would not work. Of course, for testing purposes, I could try to run it. That's why I commented out the [HttpsRequired] attribute. I will try that and report back, but for now I hope I gave you all the information you required.
I'm having a setup very close to yours (Asp.Net core, Web API, IIS, HTTPS ...) working fine on my end.
I faced the same issue at some point because I was not using the proper path to access my controller/action, it depends on how you deployed it under IIS. For instance, in my case when I use Kestrel directly it goes through a URL like that:
http:// localhost:5000/controllerName/actionName
But I can also contact my Web API via IIS and in that case I need to use a URL like that:
http:// localhost:5001/applicationName/controllerName/actionName
Have you created an application under IIS that could explain you getting a 404 because you would not use the proper path?
For instance, in my case:
screenshot of the asp.net core api under iis
And I'm accessing it, through the URL:
https: //servername:serverport/RequestPortalAPI/ControllerName/ActionName
In the end, it was a matter of properly configuring Widows Authentication. For Fredrik and anyone else reading this post for a solution, these are the steps I performed:
In IIS, in the Authentication form for my Web API, I disabled Anonymous Authentication and I enabled Windows Authentication:
Make sure that "Negotiate" is at the top of the list for Enabled Providers:
In the Application Pools, I configured my Web API to run under an account that the UIT department of my client has given me:
The configuration file of my Web API (web.config) contains the following settings:
Now we are getting into the dark areas of the problem. In order to use Windows Authentication and let the credentials of the caller be passed through to the backend (in my case a SQL Server database), the Web API has to be configured to use Kerberos. I found this after I opened a ticket with Microsoft and I worked closely with one of their engineers. For this to happen, you need to follow these steps:
Create a Service Principal Name (SPN) for your Web API and the domain account it runs under. You need to run this command:
Where hostname is the fully qualified domain name of your Web API. The Domain\Username are the domain account under which the Web API is running. You need special domain privileges, so you may want to involve someone from IT. Also, from now on, you need to access your Web API by the full domain name, not by IP address. IP address won't work with Kerberos.
Also, with the help of your IT person, you need to enable delegation for any service using Kerberos for the domain account under which you run your Web API. In the Active Directory Users and Computers, locate the account you use to run your Web API, bring up its properties, click on the Delegation tab and enable the second option "Trust this user for delegation to any service (Kerberos Only):
We have also made some changes on the server that runs our database, but I am not 100% those are truly required, so I won't add them here because I don't even know if you use SQL Server or some other backend repository.
Let me know if you need those as well and I will add them later.
Good luck,
Eddie
I want to connect to microsoft dynamics CRM via tools or code, but every time I try I get this error :
the provided uri did not return any service endpoints
Also when I go to its discovery.svc link I get the following error :
An error has occurred.
Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization's Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.
I check the IIS binding and its just bind to 5555 for HTTP and 5556 for HTTPS and also the above error occur on server side too, I mean when I go to http://myAddress:5555/XRMServices/2011/Discovery.svc both in server and clients I get the error. I cant find any thing that could solve my problem in the internet and I'm stock in this simple problem for several days.
I think after I solved my problem this could be useful for somebody. There was two problem first my server has configuration problem and server needs restart to free its memory. so it's not bad if you check how memory you are using, and if its possible restart the server.
and after that I have a proxy problem that could be fix with creating a file name app.config and writing this lines:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<defaultProxy >
</defaultProxy>
</system.net>
</configuration>
Then it'll works fine
I have a asmx web service running on a test server that has anonymous access enabled.
When I add the web reference to a console application and call a simple Hello World method like so:
PivotService.PivotService p = new PivotService.PivotService();
String s = p.SayHello();
When I do exactly the same thing in the page load of a web application I get a System.Net.WebException: {"Unable to connect to the remote server"}.
The inner exception is {"No connection could be made because the target machine actively refused it 127.0.0.1:8888"}, errorCode 10061.
Why would this work from a console app and not a web app?
It could be due to differences in the proxy settings between applications. Check out the MSDN documentation around the Default Proxy element in config file.
I too was in a similar situation while using HttpClient class from System.Net.Http namespace. I was trying to make a network call which goes through the company proxy server.
While this HttpClient call was able to successfully resolve the IP of the dns when called from a console app in visual studio the dns resolution failed when the call was made from a Web API. And it turned out that I had to have this entry in the web.config of the web api app.
<system.net>
<defaultProxy />
</system.net>
Credit to Mark 909's answer for pointing me in right direction. Please see Default Proxy for additional information.
c#httpclientwebapi
First remove web reference from console
run you web service and copy the URL
go to your solution explorer and add web reference(Exclude old one)>Advanced>Add web Reference
add paste URL then add your web reference name then rebuild your solution
it works fine for me
As #R Kiran Kumar suggests, I had to also add the proxy values:
<system.net>
<defaultProxy>
<proxy usesystemdefault="False"
proxyaddress="Specify Your Proxy Address: Specify Port Number"
// Example, "http://192.168.0.10:1234"
bypassonlocal="False"/>
</defaultProxy>
</system.net>
Use this line :
ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
Just above the httpclient object creation
[SoapRpcMethod(Action = "http://cyberindigo/TempWebService/InsertXML",
RequestNamespace = "http://cyberindigo/TempWebService/Request",
RequestElementName = "InsertXMLRequest",
ResponseNamespace = "http://cyberindigo/TempWebService/Response",
ResponseElementName = "InsertXMLResponse",
Use = System.Web.Services.Description.SoapBindingUse.Literal)]
[WebMethod]
public string InsertXML(string Jobs)
{
return "Hi";
}
The Problem when I am accessing it using XMLHttpRequest it gives following error
Server did not recognize the value of HTTP Header SOAPAction: http://Cyberindigo/TempWebService/InsertXML
The source of the next part of this post is:
http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/
(since the OP didn't want to give attribution, and thanks to Peter)
Please note that bakert is the original author of the text, not the OP.
Seeing as nowhere on the internet can I find an explanation of this error I thought I’d share the fruits of my long search for this bug.
It means (at least in my case) that you are accessing a web service with SOAP and passing a SOAPAction parameter in the HTTP request that does not match what the service is expecting.
I got in a pickle because we moved a web service from one server to another and thus I changed the “namespace” (don’t get confused between web service namespaces and .net namespaces) in the calling C# file to match the new server. But the server doesn’t care about the actual web reality of http://yournamespace.com/blah it only cares that you send it what you have said you are expecting on the server. It doesn’t care if there’s actually anything there or not.
So basically the web service was moved from http://foo.com/servicename to http://bar.com/servicename but the “namespace” of the web service stayed as http://foo.com/servicename because no one changed it.
And that only took about 4 hours to work out!
If you’re having a similar problem but can’t work what I’m saying here, feel free to mail me on bakert+web#gmail.com – I wouldn’t wish my four hours on anyone!
While calling the .asmx / wcf web service please take care of below points:
The namespace is case sensitive,the SOAP request MUST be sent with the same namespace with which the WebService is declared.
e.g. For the WebService declared as below
[WebService(Namespace = "http://MyDomain.com/TestService")]
public class FooClass : System.Web.Services.WebService
{
[WebMethod]
public bool Foo( string name)
{
......
}
}
The SOAP request must maintain the same case for namespace while calling.Sometime we overlook the case sensitivity.
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Foo xmlns="http://MyDomain.com/TestService">
<name>string</name>
</Foo>
</soap:Body>
</soap:Envelope>
The namespace need not be same as hosted url of the service.The namespace can be any string.
e.g. Above service may be hosted at http://84.23.9.65/MyTestService , but still while invoking the Web Service from client the namespace should be the same which the serice class is having i.e.http://MyDomain.com/TestService
I agree with Sam in that the SOAP definition does not match what is expected. Here is just ONE solution it could be, I had to manually figure this error for myself:
My problem was that I changed the name of the web method but did not change the "MessageName" in the metadata tag.
[WebMethod(MessageName = "foo")]
public string bar()
{
}
It should be
[WebMethod(MessageName = "foo")]
public string foo()
{
}
hope that helps someone
I've decided to post my own answer here because I've lost a few hours on this and I think that, although the accepted answer is very good and pointed me in the right direction (yes, it got a voteup), it was not detailed enough to explain what was wrong with my application, at least in my case.
I'm running a BPEL module in OpenESB 2.2 and the Test Case of my Composite Application was failing with the following error:
Caused by: System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: .
After doing some research I've noticed that the external WSDL has all the clues we need to fix this problem, e.g., I'm using the following web service to validate a credit card number through a orchestration of Web Services:
http://www.webservicex.net/CreditCard.asmx?WSDL
If you check the <wsdl:operation elements you will see that it clearly states the soapAction for that operation:
<wsdl:binding name="CCCheckerSoap" type="tns:CCCheckerSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="ValidateCardNumber">
<soap:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
...
But, once you create the Composite Application and build the project with the BPEL that invokes this external WSDL service, for some reason (bug?), the XML of the Composite Application Service Assembly (CASA) binding is generated with an empty soapAction parameter:
<binding name="casaBinding1" type="ns:CCCheckerSoap">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ValidateCardNumber">
<soap:operation soapAction="" style="document"/>
<input>
<soap:body use="literal"/>
</input>
Once you copy the proper soapAction (http://www.webservicex.net/ValidateCardNumber) into this parameter, the application's Test Case will correctly and return the expected Soap response.
<soap:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/>
So, it's a more specific solution that I decided to document based on the information found in this blog post: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/.
It means (at least in my case) that you are accessing a web service
with SOAP and passing a SOAPAction parameter in the HTTP request
that does not match what the service is expecting.
I had same problem, it fixed after some checking:
<< Target WebService Exists but called method's not eXXXists. >>
my local service contain methods but target server(connecting server)
does not contain specified called method.
Check your program scenario again...
Just to help someone on this problem, after an afternoon of debug, the problem was that the web service was developed with framework 4.5 and the call from android must be done with SoapEnvelope.VER12 and not with SoapEnvelope.VER11
I had similar issue. To debug the problem, I've run Wireshark and capture request generated by my code. Then I used XML Spy trial to create a SOAP request (assuming you have WSDL) and compared those two.
This should give you a hint what goes wrong.
My error fixed by answer Mr. John Saunders : http://forums.asp.net/post/2906487.aspx
in short: difference between Namespace of ws
.asmx.cs with ws
.wsdl files.
1) [WebService(Namespace = "http://tempuri.org/")]
later web service namespace changed to :
2) [WebService(Namespace = "http://newvalue.com/")]
so we referenced (1) in application and web service is (2) now.
make them equal to fix your problem.
I had this same problem, but the solution for me was that I was pointing to the wrong web service. I had updated the web reference correctly. But we store the URl for the service in an encrypted file, and I didn't update the file with the correct service encrypted.
But all these suggestions really helped me to realize where to go for debugging.
Thanks!
I had the same problem after changing the namespace from "tempuri" in my Web Service.
You have to update your Service Reference in the project that is consuming the above service, so it can get the latest SOAP definitions.
Or at least that worked for me. :)
We had renamed some of our webservice project namespaces and forgot to update the website httphandlers config section with the namespace of the renamed projects.
I had the same error, i was able to resolve it by removing the 'Web Reference' and adding a 'Service Reference' instead
I got this error when I tried to call a method which did not exist. It only existed in a newer version of our webservice.
I had to sort out capitalisation of my service reference, delete the references and re add them to fix this. I am not sure if any of these steps are superstitious, but the problem went away.
I had a similar problem with the same error message:
System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction:
We utilize dynamic URL's in our web service calls. We have a central configuration server that manages the location of all web service calls so that our code can run in DEV, test or live without recompiling. The URL for a specific web service call for the test environment was incorrect in our configuration server. The web service call was being sent to the wrong server and the wrong web service.
So this error can simply be the result of the web service request not matching the web service being called.
It took running fiddler on the Web App server to see that the actual call was to the incorrect web service.
the problem is in the System.Web.Services.Protocols.SoapDocumentMethodAttribute
in the service. Please check it. it may changed.
I found out that my web reference was out of date and the code was calling a removed web service.
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!