Laravel : calling your own API

If you are using Laravel to develop PHP websites (you should if you are not using it!) you will usually create your own API. If you create an API, most of the time it is because you will need to call this API from outside your website. But sometimes you want to call your API from your website. And it’s not always easy to call your own API. Let’s see a few common mistakes (it took me 1 hour to figure this out) and how to solve them.

Calling your API with no parameters

No problem here, you can use the following code:

$request = Request::create('/api/page/'.$idPage, 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());

Calling your API with parameters

This is where it gets tricky. Imagine you want to call the following URL:

http://example.com/api/page/1?section=howto

If you change the previous code with something like that:

$request = Request::create('/api/page/'.$idPage.'?section=howto', 'GET');
$instance = json_decode(Route::dispatch($request)->getContent());

And if you try to do something like this in your API:

public function show(Page $page)
{
     if (Input::has('section'))
     {
          // code
     }
 }

You will not be able to get the section parameter in your API controller with Input::has('section').

But why?

In fact Input is actually referencing the current request and not your newly created request. Your input will be available on the request instance itself that you instantiate with Request::create(). If you are using Illuminate\Http\Request in your API, then you can use $request->input('key') or $request->query('key') to get parameters from the query string. But you have a problem if you are using the Input facade in your API.

A solution (so that you can continue using the Input facade) is to replace the input on the current request, then switch it back.

// Store the original input of the request
$originalInput = Request::input();

// Create your request to your API
$request = Request::create('/api/page/'.$idPage.'?section=howto', 'GET');
// Replace the input with your request instance input
Request::replace($request->input());

// Dispatch your request instance with the router
$response = Route::dispatch($request);

// Fetch the response
$instance = json_decode(Route::dispatch($request)->getContent());

// Replace the input again with the original request input.
Request::replace($originalInput);

With this you will be able to use your original request input before and after your internal API request. The Input facade in your API will be able to fetch the right parameters.

Proper internal requests

You have seen how to make internal requests to your API, but the code is not so beautiful. If you are making only a request sometimes, it is okay to use the previous example. But if you need to do several requests to your API, you will need a cleaner code.

There is a plugin for that: Laravel HMVC, available on GitHub. With it, you will not need to replace the input for your requests to your API. You will be able to do something like that:

// GET Request.
API::get('user/1');

// POST Request.
API::post('user', array('title' => 'Demo'));

// PUT Request.
API::put('user/1', array('title' => 'Changed'));

Convenient isn’t it? You can add it to your composer.json file:

"teepluss/api": "dev-master"

HTTP error when uploading an image in WordPress

This morning I came across a problem when trying to upload an image to my WordPress blog. This error just said « HTTP error ». I noticed that if I tried to upload a very small image (< = 100 kb), everything was fine. After some Google queries (and a lot of things that said you should put this in .htaccess), I fixed this issue.

Origin of the problem

The problem was caused by FastCGI. When using PHP as FastCGI, if you try to upload a file larger than 128 kb, an error « mod_fcgid: HTTP request length XXXX (so far) exceeds MaxRequestLen (131072) » occurs and causes a 500 internal server error. This happens because the value of MaxRequestLen directive is set to 131072 bytes (128 kb) by default.

Correction of the problem

To fix this, you should change the MaxRequestLen directive from the file fcgid.conf. Locate this file:

$ locate fcgid.conf

It’s usually located at edit /etc/httpd/conf.d/fcgid.conf or /etc/apache2/mods-available/fcgid.conf and add (or replace this line):

MaxRequestLen 15728640

With this, the MaxRequestLen will be 15 MB. Restart your web server and you should be fine!

$ sudo service apache2 restart

Providing a simple 2-step authentication for your app with Google Authenticator

In this article I will show how simple is it to code in PHP a 2-step authentication for your application thanks to the Google Authenticator application for your smartphone.

Requirements

You will need Composer for your computer and the Google Authenticator application on your smartphone.

Coding

Let’s start! Create an empty directory, and put this simple composer file inside.
Open a terminal in the directory you just created and run
Now you have the famous vendor directory with the package that we need. You can view it on GitHub here: https://github.com/mauroveron/laravel-google-authenticator.

Let’s create our main file. We are not going to code a entire connection system, I will just show you how you can code a 2-step authentication system. The user will have to download the Google Authenticator application, scan a barcode and then he will have a 6 digits code every 30 seconds from the application. You will ask for this code if he has previously entered his password successfully.

Put this file in the same directory.

If you want to test this code, run this command from your terminal:

Open your browser, go to http://localhost:8080, scan the barcode from the Google Authenticator application and refresh the page. The current code (given by the website) should follow what is written on your phone. You should have something like this in your Google Authenticator app.

Conclusion

And… That’s it! You know how to generate a secret key for a user, the barcode associated with it and you have a function to check if the user has entered the right code. Of course you will have some work to do if you want to implement it into your website: you will have to explain to your users how to install the app, how to scan the barcode, to save their secret key in your users table and add a step to your login process.

But it’s not so difficult :)

Spell check for a specific file extension in Sublime Text

I’m a big fan of Sublime Text. I always write documents using LaTeX and Sublime Text. I know how to write in almost a perfect French, but everybody can do a spelling mistake sometimes. I was tired to enable « Spell check » and to select the french dictionary everytime I had to open a .tex file. So I asked myself:

Is there a way to always enable spell check with a french dictionnary for every .tex file I open?

The answer is yes! Here is how to do it.

Open a .tex file. Go to Preferences -> Settings – More -> Syntax Specific – User and put this inside:

Do not forget to change the location of your dictionary! Save this file and start typing without making mistakes ;)

Adding dictionaries

Additional dictionaries can be found on the Sublime Text Github’s repository here: https://github.com/SublimeText/Dictionaries. If you want a new language, create a new package (that is to say a folder), and put language.dic and language.aff inside this folder. You will be able to select this language after that.

Neutralité du Net en France : la dangerosité d’imposer du filtrage aux hébergeurs

L’impact d’Hadopi sur le P2P en France

La « loi » Hadopi aurait un impact assez efficace envers les utilisateurs lambdas qui utilisent le protocole P2P pour s’échanger des contenus non libres de droit. C’est en tout ce qu’affirme cette étude récente (Investigating the reaction of BitTorrent content publishers to antipiracy actions) menée par plusieurs chercheurs internationaux, dont des chercheurs de l’Institut-Mines Télécom – Télécom SudParis.

Comme l’indique cette étude :

En comparant avec les autres uploadeurs, ceux situés en dehors de nos frontières, nous avons remarqué que le nombre d’éditeurs mettant en ligne des contenus depuis l’hexagone avait diminué de 46 % entre une première période située en avril-mai 2010 et une seconde, en octobre-décembre 2011

En revanche le nombre total de contenus partagés depuis la France a augmenté de 18 %.

Si on regarde plus précisément, l’activité des uploaders occasionnels, qui partagent temporairement et avec des connexions à Internet de faible capacité aurait chuté de 57 % entre 2010 et 2011. A contrario, les « uploaders professionnels », qui mettent en partage des contenus pour alimenter des sites de torrents, seraient devenus plus actifs encore qu’auparavant. Ainsi, 29 des 100 uploaders les plus actifs de The Pirate Bay seraient originaires de France si on en croit leur adresse IP.

L’engouement pour OVH

Mais pourquoi un tel engouement pour la France ? Parce que OVH, premier hébergeur européen est très attractif pour les uploaders professionnels. En effet, OVH propose des serveurs dédiés que beaucoup de professionnels utilisent comme seedbox (un serveur dédié à la réception et l’émission de fichiers).

Et là, l’étude se met un doigt dans l’oeil. Elle pointe le laxisme d’OVH vis-à-vis de l’utilisation du P2P sur ses serveurs.

Nous avons contacté OVH pour avoir quelques informations sur sa popularité parmi les éditeurs BitTorrent professionnels, et avons appris qu’OVH ne surveillait pas activement ses clients sauf si une violation est rapportée par un tiers et que le client ne cesse pas son activité. Une telle stratégie de surveillance passive est inhabituelle. Ces dernières années la plupart des hébergeurs ont adopté des politiques de surveillance strictes pour empêcher la distribution de contenus protégés par les droits d’auteur depuis leurs serveurs à travers des applications P2P.

Pourtant OVH respecte scrupuleusement la loi en ne surveillant pas l’usage que font ses clients des serveurs dédiés loués. En France, l’article 6.7 de la loi pour la confiance dans l’économie numérique indique que les sociétés d’hébergement de données :

ne sont pas soumises à une obligation générale de surveiller les informations qu’elles transmettent ou stockent, ni à une obligation générale de rechercher des faits ou des circonstances révélant des activités illicites.

Une riposte graduée pour les hébergeurs ?

Mireille Imbert-Quaretta, présidente de la commission de protection des droits de l’Hadopi, ne semble pas être en accord avec ceci et propose la mise en place riposte graduée à l’encontre des hébergeurs dans des propositions d’amendement formulées au ministère de la Culture. Concrètement, il s’agirait d’obliger les hébergeurs à filtrer pro-activement ce qu’ils stockent, et à les mettre en garde en cas d’infractions. Puis s’ils refusent d’améliorer leurs technologies et pratiques de filtrage, l’autorité publique pourrait décider de rendre public le comportement de cette plateforme dans le cadre d’une procédure d’alerte, laquelle pourrait aller jusqu’à demander le blocage de noms de domaine ou serveurs.

Une absurdité sans nom.

La dangerosité d’une obligation de filtrage imposée aux hébergeurs

Si jamais une obligation de filtrage était imposée aux hébergeurs, ceci serait extrêmement dangereux. Avant d’être dangereux, ceci serait extrêmement difficile à mettre en place techniquement :

  • OVH loue des centaines de milliers de serveurs dans le monde ;
  • La loi ne pourrait s’appliquer qu’aux résidents français ;
  • Comment déterminer qu’un contenu mis en ligne ou téléchargé est libre de droit automatiquement (c’est-à-dire grâce à un système informatique capable d’être efficace) ? Plusieurs millions de fichiers sont échangés sur les centaines de milliers de serveurs de l’infrastructure d’OVH au quotidien.

Et puis surtout ceci serait extrêmement dangereux. En demandant aux hébergeurs de filtrer le contenu qui est stocké sur les serveurs qu’ils louent, on leur donne des droits qui sont réservés à la justice. Un intermédiaire technique serait alors en droit (et en devoir d’après la loi) de déterminer, lui seul, quel fichier peut et ne peut pas être stocké sur ses serveurs. Ceci pourrait engendrer des dérives importantes voire catastrophiques :

  • L’hébergeur incapable de proposer un système informatique pouvant déterminer automatiquement si un fichier est libre de droit ou non interdit à ses clients de modifier des fichiers en dehors des heures de bureau, entre 8h et 18h. Tout nouvel envoi de fichier vers un serveur devra être validé humainement, ce qui peut prendre plusieurs heures voir plusieurs jours.
  • Votre hébergeur ne partage pas les mêmes convictions politiques que vous et décide de censurer ou d’altérer le contenu de l’article politique faisant controverse que vous avez rédigé et que vous voulez mettre en ligne.
  • Votre hébergeur ayant l’obligation de prêter attention à ce que vous faites sur votre serveur s’aperçoit que vous développez un outil qui pourrait être très utile pour son fonctionnement. Sans vous mettre au courant, il fait une copie de votre travail.

Imaginez que quelqu’un s’amuse à censurer, ou pire, à modifier les mots que vous formulez quand vous parlez à quelqu’un, face à face. Plutôt gênant non ? Et bien ceci pourrait être encore plus grave : votre droit de publier ce qui vous chante pourrait être remis en cause.

La neutralité technologique et la neutralité du réseau ne sont pas des fantaisies techniques. Ces principes sont fondamentaux pour la protection de nos droits.

Raildar

RaildarL’open data a le vent en poupe en ce moment, et on ne peut qu’applaudir les initiatives des institutions qui font le choix de mettre à la disposition de la communauté une partie de leurs données. Dernièrement c’est le gouvernement français qui a montré l’exemple en refaisant complètement la plateforme data.gouv.fr regroupant les données provenant des services publics français.

Récemment, la SNCF s’est lancée partiellement dans l’open data. Guillaume Pepy a du faire partie de l’initiative, lui qui a promis que de nouveaux outils innovants seraient édités prochainement par la SNCF. Pour autant, on ne peut pas encore dire que la SNCF met à la disposition de ses usagers des outils appropriés pour visualiser ses données publiques.

Spyou a décidé de prendre les devants et propose depuis le mois de décembre 2013 un outil très intéressant nommé Raildar (on notera le jeu de mots !) qui permet de suivre les trains circulant en France en quasi temps réel. Comme indiqué sur le wiki de Raildar,

Les données proviennent d’une collecte permanente et (très) régulière des informations de circulation disponibles sur divers sites officiels (infolignes, gares-en-mouvement, …) et nous les avons rapproché des informations théoriques fournies par les API SNCF officielles pour créer notre propre API mêlant données théoriques de circulation et informations temps réel.

Le résultat est bluffant. Et comme un lien vaut mieux qu’une longue description, je vous donne ceci : raildar.fr.

EasyPHPCharts

Area Chart
Last week I released on GitHub a quite simple PHP class to easily build beautiful charts from www.chartjs.org. The source code can be found on GitHub here: github.com/AntoineAugusti/EasyPHPCharts. Do not hesitate to submit a pull request if you found a bug or a typo in my code. I’m quite sure that the code isn’t perfect yet.

A documentation can be found at GitHub Pages : antoineaugusti.github.io/EasyPHPCharts/. If you consider that the documentation is not detailed enough, please e-mail me! If you want to implement new features, please take a loot at the ChartJS Documentation : www.chartjs.org/docs/.

I hope you’ll be able to draw beautiful charts :)

Kids Can’t Use Computers… And This Is Why It Should Worry You

Kids and computersIl y a quelques jours, Marc Scott, un enseignant en informatique a publié un article sur Coding 2 Learn intitulé « Kids Can’t Use Computers… And This Is Why It Should Worry You » et qui a depuis fait beaucoup parlé de lui.

Dans cet article Marc relate les situations auxquelles il est confronté au quotidien : des élèves, des professeurs qui viennent lui demander de l’aide parce qu’ils rencontrent un problème avec leur ordinateur. Il s’étonne que ces personnes n’arrivent pas à régler ces soucis, assez classiques et qui peuvent être résolus avec un peu de bon sens ou au pire à l’aide d’une recherche sur un moteur de recherche. Il en arrive à la conclusion que la plupart des personnes ne savent pas utiliser un ordinateur, et que ceci est inquiétant vu la place de l’informatique dans notre société.

J’ai trouvé cet article absolument passionnant. Tout d’abord parce qu’il est bien écrit, ensuite parce qu’au-delà de la critique dans un premier temps, Marc donne des pistes sur ce qui a pu mener à ceci et des moyens pour essayer d’enrailler le phénomène.

L’article original peut être lu ici : coding2learn.org/blog/2013/07/29/kids-cant-use-computers/.
Une traduction française par Nathalie Pauchet peut être lue ici : lunatopia.fr/blog/les-gamins-ne-savent-pas-utiliser-les-ordinateurs.

Étude des données de Teen Quotes

Teen Quotes ?

Teen Quotes est un projet sur lequel je travaille depuis novembre 2010. En quelques mots, Teen Quotes est un site regroupant des citations du quotidien des adolescents à propos de leurs centres d’intérêts : l’école, les amis, les premiers amours, les premières peines. Teen Quotes est intégralement en anglais, a déjà enregistré plus de 1,5 M visiteurs et est présent sur Twitter, Facebook, le web, le web mobile et l’App Store.

Miam, des données !

Poussé par la réalisation d’un projet pour mon cursus à l’INSA de Rouen, j’ai décidé de prendre le temps de faire une analyse plus complètes des données associées à Teen Quotes. Teen Quotes étant déjà un projet ouvert (le code source est majoritairement libre de consultation), il apparait comme logique que l’étude de ces données soit publique.

Sans plus attendre, voici les liens pour consulter cette étude :