When I host a self hosted WCF, I define the URL in code.
Is there any best practice to do that?
We first had something like, 'http://localhost:8085/bla'
But that did not work for https, because of ssl certificates.
So we came up with using the full qualified host-name, instead of localhost.
And it worked for now.
But now I'm thinking about hosting the service in the cloud one day?
Will it also be OK to take the full qualified host-name there? Or is there any other best practice?
Or am I missing something?
Related
Hi everyone Does anybody know how to change the path of a defined foxx service.
I would like to have something like "IP/login" and "IP/register".
By default it is accessible under "_db/..." path.
The only way I found was to use a Webserver Like nginx to rewrite or restrict incoming URL paths. Is there a better solution?
Thanks in advance.
I'm Alan from the ArangoDB Foxx team.
If you want to expose your service to the wild, a reverse proxy like nginx or Apache is absolutely the best way to go. Keep in mind that if you allow users to talk to ArangoDB directly you're also likely exposing the HTTP API and the admin interface -- these are probably not things you want on the public web.
There's currently no way to mount a Foxx service at the "root" URL and this is unlikely to change.
I have an WCF REST service with only GET access. I'd like to make it obligatory to use SSL only on several of the service functions.
How can this be accomplished?
Thanks!
Intermixing HTTP and HTTPS on the same svc file isn't possible. You need to have an svc file that only talks HTTPS and one that talks HTTP. From my experience trying to get a specific WCF svc to respond in a mixed manner has been impossible.
You need make bindings with using HTTPS protocol + use SSL certificate on IIS
Let's say you've got a WCF service that is accessible via HTTP and HTTPS, but you want only certain methods to be available with HTTPS-- how can I check if the current request is HTTPS? Since HttpContext is empty, you can't simply check HttpContext.Current.Request.IsSecureConnection -- any other ideas? Thanks in advance.
Consider that WCF applications can also be hosted as a Windows service, with no ASP.NET at all, in which case there is no such thing as "secure" vs. "insecure." That is one reason why WCF does not attempt to make this information available.
One option would be to run the WCF service in ASP.NET Compatibility Mode, where you do have access to the HttpContext.Current instance.
My choice, however, would simply be to create a different, SSL-only service for the secure operations. I really think you'd want to do this anyway, so the contract is explicit; otherwise you're left doing runtime checks and clients may have no idea that the methods they're trying to use aren't allowed.
"Best practice" in a web service is to make these types of restrictions as explicit as possible, and having a separate service available only over SSL is by far the clearest means of describing your service's restrictions.
( Building on comment from #Aaronaught within answer by Matt Ellen... )
It looks like
OperationContext.Current.RequestContext.RequestMessage.Headers.To.Scheme
contains "http" or "https" among others (msdn).
HTTPS is served over a different port to HTTP. Assuming you know the ports, perhaps checking that would suffice.
How about:
var iwrc = WebOperationContext.Current.IncomingRequest;
var isHttps = iwrc.UriTemplateMatch.BaseUri.Scheme.Equals("https", StringComparison.InvariantCultureIgnoreCase);
This is very easy, does not rely on port numbers and works just fine in a self-host WCF server (with no IIS in site sight).
I need to protect my WCF web services and was thinking what is the best way of doing this. Its not really a ROLE / User situation - more of a "WHO CAN CALL THE WEB SERVICE".
I was thinking that i could use an IP? Is this the recommended way?
Anybody have any experience with this, I was thinking of have a table (sql) with all IPs that can access the web service but i didn't want to reinvent the wheel if something exists already.
I presume there is an event or similar when somebody access the webservice so i can check there ip? - Anybody have an example?
And i presume this can be accomplished with standard HTTP binding ?
I would appreciate any input anybody has
You can pretty easily restrict the calling IP's in your service using a service behavior.
There's an excellent CodeProject article including source code that shows how to do this. Since it's WCF and a WCF behavior, it's pluggable, too - you can add or remove it from your service as needed.
Marc
Really depends on the security level of the service. IP addresses alone are quite easily spoofed by a knowledgeable caller, so if it's a service that deals with sensitive information, I'd recommend something a little harder to break, like transport security (eg SSL) with client certificates. Very well supported by WCF and not as scary or expensive to use as you might think, especially if you control both the client and server (that way you can configure the client to ignore the cert's "trusted" status so you don't have to buy a commercial server cert).
I have been tasked to implement a WCF service that makes use of NetMsmqBinding. I wrote the service and it works fine. The problem is that in the last minute they told me that there will be no Active Directory integration. So I don't know how to configure the security of the service. There is a VPN tunnel between the service's and the client's machines but they do not use the same active directory. Please advice. Any kind of help or tutorials would be appreciated.
The problem is that the service is not always online. That is why using WCF over MSMQ is preferred for this scenario. So I am sending one way messages through MSMQ - which works fine. My only problem is that I am new to WCF and am not familiar with WCF security. I would like to be able to sign and encrypt the messages since the information to be sent to the service is confidential. I would like to make sure that only authorized clients call the service. Any suggestions?
I'm not sure I understand your question so correct me, if I'm wrong. I have recently been woring on a WCF service that was hosted on a computer with no Active Directory available. We secured it using certificates. Is it an option for you? It's pretty painless (if you get past the 'put the certificate in the store and give the correct user access to it' part).
You should be able to take advantage of network transparency.
Use webservices to communicate from one system to the other. You might have to deal with extra latency, but it should still be usable.
Well first, you can use WCF's security, the WS-* stuff. Some info here:
http://blogs.msdn.com/motleyqueue/archive/2007/10/06/complementing-msmq-security-with-wcf.aspx
Second, you might find this blog to be helpful:
http://blogs.msdn.com/johnbreakwell/default.aspx
One of the articles there about cross-domain sending mentions this article (Cross-Enterprise Support):
http://msdn.microsoft.com/en-us/library/ms705127(VS.85).aspx
Which might help you configure it in general.
Thank you, Michael, but this information wasn't helpful...
I found this: http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=14070 - a book from "Microsoft Pattern & Practices" which describes in detail the security in WCF - a must-read for every WCF developer.