Can someone please help with how I configure my WCF service. The environment is IIS6 and the service can only be accessed via https (the firewall only allows connections to the server on port 443).
So, when I access https://myservice.com/Service.svc it gives me the URL of the WSDL file, which is the correct https address (I got this working by enabled httpsget, i think, there has been a lot of guess work!)
However, if I then consume the service, the end point address is http://localservername/Service.svc.
I assume I need to configure my web.config file to return the correct soap address, but having googled and read so many posts about endpoints, binding and behaviours, I am confused.
Can someone please clear this up for me, how do I configure my service to allow https connection and get the correct SOAP address?
Cheers
Chris
Does this help?
http://weblogs.asp.net/srkirkland/archive/2008/02/20/wcf-bindings-needed-for-https.aspx
Quote the Note:
"Just one note: after 3 hours we realized that webHttpBinding is not suitable for regular SOAP-based clients (one has to watch these bindings :) We switched webHttpBinding to basicHttpBinding and our SOAP-based clients were able to parse the generated WSDL and to consume the web service."
Related
I have an WCF Webservice project, built in my local machine, which when hosted using test client and triggered, returns values from remote database in JSON format.
For example, if you key in the URL with localhost then you get results back in the below format:
{"Id":3,"Value1":"67.5687","Value2":"126.7125"}
I want to host this project on a remote server with a public URL, which should return the above results back from any network. I have 3 question regarding this:
** What modifications should I do to my current WCF project to host it on remote server.
** Given the various types of hosting like :
1) windows process activation services (WAS)
2) IIS
3) Self hosting
4) Hosting in a Windows service,
which type of hosting is best suited for hosting on remote server.
** What changes should I make in my App.Config file (including the change in my endpoint address from localhost to IP address) to make the service work.
Thanks.
1) You shouldn't need to make any changes to your project just because you want to host the code on another machine. I find this an odd question.
2) Given your choice of JSON as data format and a browser as test client, I'm guessing you want to make it available over HTTP using simple GET requests. In the Microsoft stack, IIS is the web server, and the natural choice for this scenario.
3) It is quite impossible to answer. I don't know what's in your app.config today. I don't know if you're going to authenticate, and if so how. And I don't want to know! That said, it seems to me if everything is supposed to behave as it does on your dev box, the bindings are already ok. I don't remember if a WCF service needs to know about the endpoint it is itself at (hard to see why it would need to know this, really); I would have thought it more natural to do such configuration on the host, e.g. IIS. The client of course should use a different endpoint pointing to wherever you host the service. (You can put many endpoints in app.config and let the user choose one, btw.)
I think most of us sin against the following advice now and then, but it is the best advice I can give: Read a book. Learn as much as possible about the thing you're using, in this case WCF. You'll get the time back later, and your software will be less bad!
How do I get around this error
**The Requested FTP command is not supported when using HTTP Proxy**
occur on the following code
ftpWebRequest.Method = WebRequestMethods.Ftp.DeleteFile.
It is urgent. Can anyone give suggestions for this problem
Your proxy might be blocking FTP delete keywords when filtering requests.
Can you check if you are able to do this activity when not in the proxy (try from a different network where you connect directly).
if yes, i dont think it is straighforward for you to do this activity from behind proxy.
Another solution is to try open source ftps libraries http://ftps.codeplex.com/
or
1. Create a WCF service on the FTP server which allows you to do all that you want.
2. From client side make call to the WCF service passing the command.
So far I've been successfully using fiddler to sniff web service traffic from both test fixtures, console apps and web projects.
Today I noticed I am not able anymore to sniff that kind of traffic if I am running my web application (it's a ASP.NET website, hosted locally on IIS). I see all the local traffic but the web service traffic is just gone (the service is being hit as I do see the response debugging into the code).
I am still able to successfully sniff soap requests and responses from test fixtures or console apps in the same solution (exact same environment).
If it was a windows (I am on Win7) security update or the likes it would never work I guess (unless it affects only traffic routed through IIS).
What should I be looking for that could cause the emergence this behavior?
Any pointers appreciated!
NOTE: I can see local traffic, but not the SOAP request/responses to the web service which is not hosted locally anyway (it's a sandbox another team is providing)
EDIT: This bit of configuration did the trick (found on Rick Strahl's blog)
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
What's the client of the web service? ASP.NET?
ASP.NET traffic isn't proxied unless you configure ASP.NET to use a proxy. It's possible/likely that the app.config or machine.config changed such that traffic is no longer getting proxied?
You should have a look at this section: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
If you want to view the http traffic between your web site and your web service on your development machine, and don't want to change your machine.config.
One easy solution is to change the Application Pool Identity of your web site to use your own credentials of the current logged on user. This means that your web site will adopt your proxy settings and will now redirect to Fiddler.
Make sure the web service you are calling (from IE) is not http://localhost/yourwebservice
Fiddler will not intercept localhost traffic from IE, use http://machinename/yourwebservice instead.
I ran into this issue a week or so ago. Try this page: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhosthttp://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
The ipv4.fiddler was the part that worked for me. Hope this helps.
You're probably using a port other than 80 for these http requests. I remember setting up a reverse proxy to look at WCF requests I was making on my local machine during dev. Here's the documentation:
http://www.fiddlertool.com/fiddler/help/reverseproxy.asp
Can you try the following -
Try stopping the windows firewall and see what happens
try using firefox and redirecting traffic to fiddler and see what happens
I have an application that is using ActiveDirectoryMembershipProvider to grant access to users. The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
We've opened the LDAP port to the DC on the inside network - yet no matter what we try, we end up with an error that says "The specified domain or server could not be contacted."
Does anyone have any suggestions on how I can resolve this? We've tried everything we can think of and just aren't getting anywhere.
My connection string is:
<add name="ADConnectionString"
connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/>
And my provider is:
<add name="ActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider"
connectionStringName="ADConnectionString"
attributeMapUsername="SAMAccountName"
connectionProtection="None"
connectionUsername="LdapUser"
connectionPassword="LdapPassword" />
The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
Since you could query directly using an LDAP tool, that suggests that the firewall is open correctly. However, keep in mind that the ActiveDirectoryMembershipProvider is not using plain old LDAP, it's using Microsoft technologies. For example, if you set connectionProtection="Secure", ADMP will try using SSL and port 636, if that fails, it will use Microsoft's built-in IPSec signing (see this article for more details).
Anyway, this makes me wonder about a couple things:
Does the AD domain have an IPSec "required" policy which refuses connections from non-domain/non-configured computers? (Probably not, since you connected with plain LDAP, but it's worth investigating.)
Have you added the domain controller's NetBIOS name to your lmhosts file, and its DNS name to your hosts file? (Many protocols check that their target's reported name matches the name you tried to connect to.)
A lot of people have noted problems using ADMP between different domains, and the solution required that a one-way trust be created. Since it sounds like your client computer is not in a domain, you can't have that trust--unless either (a) it is a member of a different domain with a one-way trust or (b) it is a member of the same domain and thus client-server trust is implicit.
It seems like the solution is to open port 445.
Read this thread
We're not allowed to open so I guess I'm stuck.
You can use this two articles, may be solve your problem
www.ddj.com/windows/184406424
forums.asp.net/t/1408268.aspx
and check your firewalls
I had this error, and managed to fix it. There are multiple reasons that can lead to this, here is a to-do list to identify exect problem:
Create a micro application, with single method Membership.GetAllUsers(), execute on machine outside Active Directory (AD), with incorrect password in connection string, check if you get incorrect password exception. If you don't get it you can't connect to your AD server, check firewall, if you do get invalid password exception, goto next step.
If you can, try to execute same app, localy on AD server, first with incorrect password, than with correct, executing app locally provides more detailed exception what is wrong (for me this exception lead me to fixing problem). In my case it told me that Server service is not started, than that Workstation service is not started.
Some thoughts on the fact that it required Server and Workstation services to be working on server: afaik Server service is used for windows file sharing (netbios over TCP), and is using 445 port, so it mey be that this port must be opened in addition to LDAP port. My second observation was that event if 445 port opened (netstat -an) it still can be not working, winows will drop all packets to this port if Windows Client and File and Printer sharing checkboxes are not checked on network interface adapter which rcived this packets. Check "telnet External_IP 445". Thats all info i gathered while strugling with this problem.
Have you tested with an LDAP browsing tool, from the remote box to see if it can connect with the criteria being used here? I.e. Is it a connectivity problem or something else?
In case anyone stumbles on this and wants to smash their head on a wall... Recently tried doing all this for an AD server that my company had in a different domain than the current context. Was using the IP provided and getting failures as stated here. Even used a tool like Softerra LDAP Admin and it worked fine, however AccountManagement failed.
We had a publicly exposed URL hooked to that IP address (still only allowing certain IP's to make calls). Once I replaced the IP with the URL provided, it worked like a charm.
Hope this saves someone the hours of head smashing I just put myself through.
I have developed a web service and host it on my server and I would like to know who is using this web service (site Url). I tryed to use "Request.UrlReferrer" but it is not returning any thing! any suggestions/Advices?
You can't get the URL of the caller of a web service as not all callers have canonical URL's. You can however get the IP Addresses assuming that they are not behind a proxy / nat. In which case you'd get the IP of the nat / proxy.
Assuming your using an ASMX web service you can this from:
HttpContext.Current.Request.UserHostAddress
Once you have the IP Address you can try and do a reverse lookup to get the host name. I would recommend storing the IP address then writting an offline process which goes and tries to determine who owns the IP. I'm sure there are some webservices out there to help with this.
You can use Request.Url property to get all the information about the requests to your web service.
The referrer is set by the client, and the client can not set it. That is why you see nothing. If the client's are servers, then the best you can do is to get the IP of the client connection and go to that IP. If a simple setup, with no virtual hosts, then that is the "web site" that is hitting your web service.
As Josh states, the HttpRequest object is the way to go, there are a few properties on there that might help:
UserHostName - Gets the DNS name of the remote client.
UserAgent - Gets the raw user agent string of the client browser.
UserHostAddress - Gets the IP host address of the remote client.
Which might give you a bit more information to play with.