My ios app retrieves some data from third party servers during runetime.
For privacy reasons, I want to hide the IP addresses of my users, in order to prevent those servers to know them. How can I do that ?
My idea is to set up a kind of "proxy server" or "VPN server" inbetween the app and the third party servers. Is that a good idea ?
Thanks for your help!
Yes, proxying is the right way to do this. You could do it with a VPN, but that's overkill, and requires considerable setup on the client side which you don't control.
You can get a web server such as Nginx or Apache to act as a proxy directly through config options, or you can do it via scripting with PHP or whatever. I do the latter to provide a proxied service to gravatar.com. The principle is quite straightforward:
Accept a request from your client.
On your server side, make a request (using an HTTP library, such as Guzzle) to the 3rd party service to get whatever is needed.
Parse the response from there and create a response suitable for your client.
This way the 3rd party service will only ever see the IP of your server, not your client, and you can choose exactly what data from the client you pass through. In my gravatar example, it sends an MD5 hash of the user's email address, which has its own privacy implications, but that's a separate problem!
Related
I'm new to mobile development and was wondering if it is an anti-pattern to have a remote, configuration server in order to 'configure' a mobile client. The idea is to avoid configuration details [except the URL to the configuration server] with the mobile distribution and rather connect to the configuration server to grab other details such as third party keys, service endpoints, etc. Any thoughts. Thanks in advance!!
So long as you are able to secure connections to the the configuration server, using a username/password and SSL encryption it's not an anti-pattern. It would save you from publishing new applications versions just to update some configuration.
What does however sound like a bad idea to me is keeping third-party API keys inside a mobile application.
Can you guarantee that each an every user using you application will not use the keys placed inside the mobile application to use the third party service to their own ends? I don't think anyone can make that guarantee.
I'm at the beginning of trying to understand the requirements for developing a VoIP app. From what I've learned so far, frameworks that allow for communication using SIP/TCP are the best (I don't intend to implement SIP myself).
However, although SIP can be peer-to-peer, its recommended to use an SIP server service. But I'm finding it difficult to locate information about what SIP services are appropriate for an iOS application / what is required from me in terms of setup of the server so that I can concentrate on client-side development.
Any advice would be much appreciated.
You need to figure out your use-cases to decide. A SIP server is like an HTTP server, it will analyse the request URI, the request headers and whatever hints it can see to execute some resource at the backend. Think if you plan to have a user database and authentication. Do you want presence? Do you want voicemail, call transfers, pbx features? Do you want video, audio, IM? Do you want to support arbitrary endpoints? Encryption, NAT traversal, HA? Only then you can think about actual servers and hosting. Many "minimal" configurations will include at least one SIP/media front-end (for NAT/SBC), a SIP/media server (to act on requests), a database server (to store persistent state) and an HTTP server (for config/admin UIs). While there are products that combine some of these into single server, they are generally at least reasonably isolated modules.
Since many website will calling service by Web API. In that case, those methods will be exposed for every one. How can I ensure only my web site can calling my Web API service?
One of the easiest way to secure it as a developer is to get the IT people to do it by limiting access down by IP address from site to site. You could also do this in the app by validating the incoming IP addreseses. Sometimes IP addresses change sometimes they don't. Whenever I have done this have used certificates as there is a trust on both sides of the data divide. Have a look at John Petersens article Making web api's secure it has a section on implementing IP security in your app as well as x509 certificates; complete with code examples that I wont reproduce here. You could try and secure it with SSL and create your own key / trust but its easier to maintain (imo) using x509. Perversely it was much easier in the web service world Microsoft had an API to do this much more simple in WSE extension..
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.
So, I'm researching methods for building a client interface for existing EMRs. I've read tons of info on HL7, as well as the various coding schemes, but I'm still really clueless.
For anyone whose worked with an EMR before: is it possible to build a web interface that can use HTTP-POST and HTTP-GET requests to pull/push data to the server database? Or would you have a separate database for the client, say a web application, then use some interface engine like Mirth to communicate between the EMR database and the web application?
A web service API is definitely a way to go. One benefit to this is that you can get https almost out-of-the box for encryption of data in transit.
The way we have configured our EMR is that we have a tcp server accepting incoming hl7 messages from certain IPs which connects directly to our EMR database. This can be beneficial by separating emr and interface processes (You don't have to restart your whole EMR if the interface goes down, for instance).
Another good feature would be to have a token system for pseudo-authentication. This only works if you are going over a secure connection though.
If you aren't into writing your own tcp server (not that hard), an api-based server is probably just as good.
EDIT: What language(s) do you think you'll be using?
Other things that you might run into:
Some applications prefer file drops to direct calls (either url or tcp)
Some vendors will have their own software that sits on a server of yours
Don't forget the ACK.
I don't see why you couldn't do this. You would need to build the web service to handle requests with a specific Uri. When this Uri is called the web service uses the data sent with the request to make changes in the database.
Once you had the web service built, you could build some sort of front-end that displays your information to the user. And makes HTTP-GET and HTTP-POST calls.
There is a lot of flexibililty in what you are trying to do... so go with a plan for sure.
In general though you should be able to accomplish what you need to do by building your own web service and front-end application that is able to manipulate an EMR database.
It really depends on your architecture and requirements.
Architecture 1
If you want your client to be web based, but your client is a separated app from your backend, then the web sends the info using HTTP to your client app server side, and then, that will send info to your EHR backend (another app). That second communication might be written using a standard, that will help you on integrating more systems with your backend in the future. So that interface can be HL7 based, if HL7 v2.x is used, take a look at the MLLP protocol: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=55
This is the most performant way of communicating HL7 data. If you don't want to deal with TCP, there is a proposal for HL7 v2.x over HTTP. HAPI implemented that: http://hl7api.sourceforge.net/hapi-hl7overhttp/
If you don't want to use HL7 v2.x but HL7 v3 (a different standard, not really a version of 2.x) or CDA, you can use HTTP or SOAP.
Architecture 2
But, if you want your client just to be a UI on the user side (browser), HTTP POST will suffice to send info from the browser to the server. That means your EHR is a centralized EHR with a web iu.
In the 1st architectural case, first case you'll probably have multiple client apps (full EMRs apps) and a backend EHR server (centralized backend). On my developments I follow this second architecture.
Also there Mirth might help to manage all the communications between client apps and backend apps. In the 2nd case, using Mirth is nonsense, is just a web application and the client communicates directly with the web server. Of course, you can use Mirth as a web server, but that's not it's role, it is an ESB no a web server.
Hope that helps!