I am building a WCF service now, that has a wsHttpBinding endpoint.
The client for now is WPF.
I would like to know if in the future, it would be possible to develop an iOS application that would be able to connect to my WCF service endpoint (it has to be wsHttpBinding, because I need security, reliability and ordered messaging).
Thanks.
I researched a bit and from what I found, it is not possible (at least not easily), please inform me if there is a way
For security I followed the following solution, which fulfills my needs:
Building .NET WCF service for iPhone with authentication
Usually not, but it depends how you configure the WSHttpBinding. If you use any kind of message level security almost surely you will not be able to call it from iOS. I'm saying almost b/c iOS supports sendins soap over http and some of the scenarios (useranme) are not complex so in theory you could manually push them to the soap. But for the most part basicHttpBinding is better (and also prefer transport security).
Related
I'm responsible for a project that is producing the server backend for an iOS application.
I would like to formally define the service interface for the clients to call so both the IOS, Android and server teams can practice contract-first development.
In the dark past we would have used WSDL and generated RPC-style client and server interop boilerplate from that. However this isn't the norm for IOS projects. We've also looked at Apache Thrift, but there is no code generator for Swift and the Objective-C generator seems to produce code that relies on deprecated IOS APIs.
Which brings us to REST, which works well as a way to move object state around. It seems less good for the kind of conversation that says "Hey server, do X with these parameters and return me a result." We just end up creating server-side controllers for particular actions, and those "define" the service's calling convention by being sticklers for getting the right parameters. Contract-last.
Is there a standard way to do contract-first web service development for iOS clients, or am I just going to have to treat documentation as the spec?
tl;dr: No.
I'm not aware of a 'standard' way of doing things, but many
client/server apps today do use some incarnation of a RESTful
interface. JSON is the usual format.
There are some well documented 3rd party utilities that can handle
this for you client side (like [RESTKit][1] in the case of REST), or
you can roll your own implementation based on apple's provided
NSURLSession or a networking library like [AFNetworking][2]
If needed, iOS can also handle socket-based communication. (3rd party
libs exist for this as well.)
[1]: https://github.com/RestKit/RestKit [2]:
http://nshipster.com/afnetworking-2/
Can we consume WSHTTPBinding service in iPhone Application?
I am trying to consume such a service, but I am getting status code 415. I also tried it with all different possible ways but getting same error code everytime.
In one article, I read that, to consume WSHttpBinding services, .NET 3.0 is required on client side.
So is there any way to consume the WSHttpBinding service in iPhone applications or its not possible.Need some guidance on this one.
Thanks in advance.
There is a response to your question here.
Short answer is "Usually not, but it depends how you configure the WSHttpBinding. BasicHttpBinding is better (and also prefer transport security)."
As I know the situation with iOS+WSHTTPBinding didn`t changed.
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
I'm mildly familiar with DotNetOpenAuth and OAuth in general, but in terms of Web API development, what is the best way to lock down a web service in terms of the following criteria:
Ease of implementation
Interoperability/compatibility with end-user facing platforms (iOS, Android, Win Phone, Flex...)
Whether or not it is clearly standards-based (like OAuth for example)
Thanks!
please take a look here: OAuth 2.0 in Web API
Inside the WebApiContrib project there are also Basic Authentication samples which is straight forward but it should not be used without SSL.
The DotNetOpenAuth .zip download includes a sample WCF service that is protected by OAuth.
There are a couple of wcf web api implementation to handle authentication on internet. I have done one as well # http://misaxionsoftware.wordpress.com/2011/07/29/secure-restful-web-service-by-wcf-web-api-no-https-seriously/
Note: code is based on Preview 3, some class name has changed in Preview 5.
The idea of implementation is ensure secured communication without SSL.
It's easy to construct. The function is transparent to your service because all the work is done in message handler. You don't bother to call the authenticate function in your service method.
Compatible with end-point where RSA encryption is supported.
Standards-based, hmm... Standards varies from case to case...