Whether you want to develop a web application or a smartphone one, you will probably be concerned with its successful operation and availability. Here is some advice to allow you to get the best from our platform.
Direct access to restricted datasets¶
As you may have noticed, some of our data is only available if you already have an account and the authorization to use it. As soon as you implement these pieces of information in your code, it’s up to you to take care of their safety, non-disclosure and their ease of use all through their life cycle (software updates, deletion…)
In PHP, Python, Java¶
No problem with these server-side languages for which you can follow the provided Examples and code snippets
On mobile platform¶
Applications developed on the mobile platform are quite safe, as they are generally compiled and are thus distributed to the users in a format which is really complicated to reverse-engineer and therefore retrieve the information written into it. On the other hand, you must consider a practical aspect tied to your credentials life cycle. Should you change your login, or even your account, how will the diffusion occur of the new credentials among all the devices using your software? Will the user have to update their software? Can you force this software to be mandatory? How many users are you ready to lose in such an operation? You must take this into account before starting to spread out your solution.
Another important question is about our platform performance. It is not sized to carry out the same workload as www.google.fr. If your application is successful, which we hope it will be, if a single tweet boosts it towards popularity summits very quickly, are you sure that our infrastructures will hold the sudden load and allow your users to have the best experience with your application?
For each of the below situations, you have to take care of the implementation of the recommended practices. The simplest way is sometimes to directly retrieve the data and serve it from your own premises.
Your user rights allow you to retrieve the data and store it on your own servers. The retrieval frequency must be set according to their update frequency. Once implemented into your infrastructure, the resolution of the previously mentioned problems is far easier:
- on mobile, the users direct access to your own version of the data. If your credentials change, it only affects your data retrieval script and not the application deployed on your users devices, which can use your own authentication/authorization system and procedures.
- for performance : punctual retrieval, even frequent, has a minimal effect on our platform . Provided that your own infrastructure is correctly sized to hold the load generated by your application, you’ll have no problem to fear on our side.
- the impossibility of hiding the credentials to use for accessing the data. You can however have set, after having retrieved the data, a user specific authentication system, in which case you have already solved a part of the problem.
- Access to a third-party domain in Ajax. This is strictly forbidden by the “Same Original Policy” which forces the ajax retrieved content to be located in the same domain and same port as the main web page from which the request has been emitted. This rule doesn’t apply to images, which explains why we can have WMS external streams working perfectly well, but applies to all other types of services : WFS, JSON or KML. Please note that our servers are configured for allowing external domain connections through Ajax request, but if you rely on other data servers, you may face this kind of situation.
In order to get around these restrictions, you can use the proxyfication trick. The basic principle is to send the Ajax requests to a script located on your own server (so having the same origin and port as your main page), which will transfer these requests to the external service, without suffering from the same constraints as the client. This can also be done to distinguish the credentials used to access your server from the ones used to access ours.
- WEB CLIENT——> PROXY SCRIPT ——> EXTERNAL SERVICE
Implementing a proxyfication script is rather trivial, but you have to respect a few rules. Don’t leave it open to anybody for instance, or it will be used by malicious people to surf the internet anonymously. And don’t let it do whatever the user asks it to either. Control the accepted operations and reject all others.
The python script used below is shipped with OpenLayers under the proxy.cgi name. This python script perfectly fits the needs for WFS usage. To activate it, you have to put it in an executable directory of the web server (generally cgi-bin suits this need), set its own rights to make it executable (i.e. chmod a+x proxy.cgi) and indicate its existence to OpenLayers for it to use it as a proxy (because OpenLayers is smart but not psychic !) with the directive :
OpenLayers.ProxyHost = "/cgi-bin/proxy.cgi?url=";
For any further information about the use of OpenLayers and a Proxy script, please refer to the dedicated FAQ : http://trac.osgeo.org/openlayers/wiki/FrequentlyAskedQuestions#ProxyHost
This PHP script does exactly the same :
As seen, there are different strategies to choose from according to the streams you want to use and the kind of platform you are developing for. Using WMS in a web application will be easier than dealing with heavy WFS in an iOS app. One can however consider the most prominent approaches :
- For simple images, without authentication, use the direct stream to our premises.
- For heavy loaded text streams (WFS, JSON…), retrieve the data regularly and serve it from your own server. It can also allow you to avoid the use of a proxy script.
- For nomads applications on smartphones, you should prioritize the autonomy of the application over the data access methods. Retrieve the data, implement a service able to list the available data in a way you can later add new data layers to your application without having to update and redeploy it.