Accès à un serveur externe

Bonjour,
J'ai déjà eu l'occasion de réaliser des petites applications android faisant appel à un serveur externe, le plus souvent des applications qui viennent en complémentarité d'une autre application web. L'idée était donc d'échanger avec un serveur mysql, tout simplement. Pour cela, j'utilisais le web service REST.
Côté serveur, je créais des pages PHP qui parsaient du texte en JSON (fonction encode_json($array) si je me souviens bien...), et du côté Android je récupérais cette page avec un http_request qui tournait dans un Asynctask.

Aujourd'hui je veux réaliser une nouvelle application Android où l'utilisateur aura besoin de s'authentifier dès le début. Les "comptes d'utilisateurs" doivent être stockés sur un serveur externe.

Question : Comment faire ça ?
Est ce que je dois monter une base mysql, avec juste une table d'utilisateurs / mots de passes chiffrés, et un serveur web + php juste pour envoyer au terminal mobile un "CONNECTED" encodé en json ?

Je ne sais pas si je suis très explicite, en fait, mon utilisateur à besoin d'échanger avec un serveur externe JUSTE pour l’authentification, mais ensuite l'application android est autonome...

Avez-vous des pistes à me proposer ?
Merci d'avance :)

Citation:

---

Question : Comment faire ça ?
Est ce que je dois monter une base mysql, avec juste une table d'utilisateurs / mots de passes chiffrés, et un serveur web + php juste pour envoyer au terminal mobile un "CONNECTED" encodé en json ?

---

Ce serait plus simple d’exécuter une requête HTTP avec tes identifiants (en méthode POST) et tu récupère ensuite la réponse.

Si toutefois, dans le cycle de vie de l'application, t'a besoin de garder le nom de l'utilisateur (JAMAIS LE MOT DE PASSE !!!) utilise la puissance des SharedPreferences

Bonjour anto2b,
oui la requête HTTP c'est ce que je faisais avant, mais là, juste pour les identifiants, ça m'étonne de devoir remettre en place tout ce système. Il y aura bien quelque chose de plus simple quand même... non ?

Pourquoi ne pas stocker aussi le mot de passe? (chiffrer si tu veux)
dans un ficher ou base de données Sql lite

car ce n'est pas normal de demander le user et le mot de passe à chaque fois qu'on lance ton appli.

Tu peux toujours faire un service rest qui prend le user et le mot de passer passés dans le header de la requête (avec un mode d'athentification, basic suffira)

ce sera une requête GET qui te renvoie true si c'est un user valide false sinon, que tu deserialize en JSON par exemple.

Citation:

---

Envoyé par chamamo

Pourquoi ne pas stocker aussi le mot de passe? (chiffrer si tu veux)
dans un ficher ou base de données Sql lite

---

C'est presque une bonne idée... mais elle doit être plus subtile... Si le serveur n'a pas son mot à dire avant l'authentification, toute tentative de sécurisation est vouée à l'échec (si A veut s'authentifier avec B, il *faut* que B commence par donner des informations à A).

Quel est le but d'une authentification ? Etre sur, pendant une session de communication donnée, que la personne à qui l'on parle est bien celle que l'on pense.
L'authentification est donc à deux sens: il faut que le client puisse authentifier le serveur, et que le serveur puisse authentifier le client.

Pour se faire il existe une solution simple: https
Le client se connecte en https au serveur (authentification du serveur par la clé publique de celui-ci, proprement signée par une autorité compétente).
Puis passe des informations d'authentification (login+password).
Mais le password ne peut pas être stocké tel quel... il est ainsi suggéré de stocker un hash du password+login... ainsi le passage login + hash pourra être vérifié coté serveur (celui-ci peut conserver le password en clair si cela lui chante, mais ce n'est pas recommandé pour des questions de sécurité, il lui suffit de strocker le hash).
Mais attention, si ces informations sont compromises, n'importe qui peut se faire passer pour la personne !

Citation:

---

car ce n'est pas normal de demander le user et le mot de passe à chaque fois qu'on lance ton appli.

---

Ca dépend... je ne suis nullement choqué de voir l'appli de ma banque (ou Paypal) me demander le password à chaque connexion.
D'autre part, Android met à disposition des outils de gestion des comptes "AccountManager", permettant de stocker de manière "sécurisée" des informations d'authentification. Mais hélas, cette manière de procéder, si elle permet d'authentifier le téléphone, ne permet pas d'authentifier la personne qui s'en sert....

Citation:

---

Tu peux toujours faire un service rest qui prend le user et le mot de passer passés dans le header de la requête (avec un mode d'athentification, basic suffira)

---

A condition de passer par https bien entendu... sinon, les informations passent en clair sur le réseau, et n'importe quel "homme du milieu" peut les récupérer et s'en servir pour se faire passer pour le client.

Citation:

---

ce sera une requête GET qui te renvoie true si c'est un user valide false sinon, que tu deserialize en JSON par exemple.

---

Si c'est un web-service correct... il devrait renvoyer un 403 si les informations ne sont pas bonnes... pas un "false" ou un "true" ;)

Sinon, il faut continuer d'authentifier l'utilisateur tout le long des requêtes... et pour éviter de faire du https (qui est quand même bien plus lourd que http) sans arrêt (pour des informations sans risque), il faut en général utiliser un "token".
Un "token" est émis par le web-service en réponse au login. Le "token" permet de connaitre l'identité (et l'authenticité) de l'utilisateur *SANS* accéder à la base de données. Il ne doit être relisible que par le web-service (peut importe pour le client son format), et peut contenir des choses comme l'ID de l'utilisateur (plus pratique que son login), un numéro de session (incrémental), une date limite de validité, une adresse IP (non recommandé pour les mobiles qui peuvent en changer souvent), un cookie de session, ....

Bonjour à tous,
Merci pour vos réponses,

Je souhaiterais cependant avoir un peu plus de précision sur ce qu'a dit nicroman :

1.
--> Si je veux faire du https, est-ce possible de commencer sans payer pour faire signer la clef ? Sur un navigateur web, on doit accepter le certificat, mais dans une appli android, comment ça se passe ?

2.

Citation:

---

Envoyé par nicroman

Si c'est un web-service correct... il devrait renvoyer un 403 si les informations ne sont pas bonnes... pas un "false" ou un "true" ;)

---

--> Comment renvoyer un 403 ? Est ce que ça a quelque chose a voir avec JSON ?

3.

Citation:

---

Envoyé par nicroman

Sinon, il faut continuer d'authentifier l'utilisateur tout le long des requêtes... et pour éviter de faire du https (qui est quand même bien plus lourd que http) sans arrêt (pour des informations sans risque), il faut en général utiliser un "token".

Un "token" est émis par le web-service en réponse au login. Le "token" permet de connaitre l'identité (et l'authenticité) de l'utilisateur *SANS* accéder à la base de données. Il ne doit être relisible que par le web-service (peut importe pour le client son format), et peut contenir des choses comme l'ID de l'utilisateur (plus pratique que son login), un numéro de session (incrémental), une date limite de validité, une adresse IP (non recommandé pour les mobiles qui peuvent en changer souvent), un cookie de session, ....

---

--> C'est interressant, mais là encore, est ce qu'il existe des ressources / tutos sur les tokens en Java Android ? J'ai trouvé [ame="http://www.youtube.com/watch?v=_JjWqwWWcVE"]ça[/ame] mais je n'aime vraiment pas les tutoriels vidéos. Serait-il possible d'avoir un exemple écrit ?


Merci =)

Citation:

---

Envoyé par poussinvert

--> Comment renvoyer un 403 ? Est ce que ça a quelque chose a voir avec JSON ?

---

En fait c'est même une erreur 401
(et cela n'a rien à voir avec JSON, c'est la base de HTTP, donc de REST).

Citation:

---

Envoyé par nicroman

C'est presque une bonne idée... mais elle doit être plus subtile... Si le serveur n'a pas son mot à dire avant l'authentification, toute tentative de sécurisation est vouée à l'échec (si A veut s'authentifier avec B, il *faut* que B commence par donner des informations à A).

---

Je ne suis peut être pas aller jusqu'au bout de mon raisonnement, on peut imaginer une activité config ou tu renseignes tes identifiants qui seront stockées en local, et à chaque fois qu'on veut communiquer avec le serveur on récupère les infos d'authentification stockées, ça t'évite de tapper tes identifiants à chaque fois que tu lance l'appli.

Citation:

---

Envoyé par nicroman

Pour se faire il existe une solution simple: https

---

Simple je te l'accorde mais comme tu l'a détaillé par la suite, est ce qu'on besoin de le mettre en place dans un réseau local?

même en utilisant du HTTP on peut crypter le mot de passe (authentification basic par exemple) dans le header de la requête HTTP.

Citation:

---

Envoyé par nicroman

Ca dépend... je ne suis nullement choqué de voir l'appli de ma banque (ou Paypal) me demander le password à chaque connexion.

---

Moi non plus avec l'appli de ma banque, je serais choqué pr contre si le téléphone me demande de mettre mon mot de passe à chaque fois que je consulte ma messagerie, car il s'agit de la fréquence d'utilisation, on ne va pas sur paypal tout les jours, contrairement à ta messagerie.

Effectivement en respectant le protocol, renvoyer 401 c'est mieu, comme l'opération d'authentification n'est pas visible à l'utilisateur (contrainrement à un browser) je peux intérpreter le résultat de l'opération dans l'appli local, si je reçois true, je suis bien authentifié, false afficher un message d'erreur. :)

Citation:

---

Envoyé par chamamo

même en utilisant du HTTP on peut crypter le mot de passe (authentification basic par exemple) dans le header de la requête HTTP.

---

Non, n'importe qui qui voit la trame http, peut récupérer le header, et l'utiliser à tout moment pour se faire passer pour la personne originelle...
C'est la base de la cryptographie... pour éviter le "man in the middle" il faut que le serveur démarre la négociation (digest-auth par exemple). Mais https permet de le faire automatiquement dans la couche liaison, c'est quand même plus simple.

Citation:

---

Moi non plus avec l'appli de ma banque, je serais choqué pr contre si le téléphone me demande de mettre mon mot de passe à chaque fois que je consulte ma messagerie, car il s'agit de la fréquence d'utilisation, on ne va pas sur paypal tout les jours, contrairement à ta messagerie.

---

C'est surtout à mon avis une question de sécurité ;)
Une norme comme PCI par exemple implique qu'un mot de passe ne puisse:
- ni être stocké en clair (c'est la moindre des choses).
- ni stocké sur une machine physique prédéfinie (par exemple il est impossible de stocker un mot de passe, même chiffré, sur un serveur dans un "cloud").

Citation:

---

Effectivement en respectant le protocol, renvoyer 401 c'est mieu, comme l'opération d'authentification n'est pas visible à l'utilisateur (contrainrement à un browser) je peux intérpreter le résultat de l'opération dans l'appli local, si je reçois true, je suis bien authentifié, false afficher un message d'erreur. :)

---

Dans ce cas, c'est plus REST surtout...et on parle bien de service REST non ?
(enfin... pour moi REST = HATEOAS)

Et puis même au niveau code c'est quand même plus simpel aussi non ?
Version JSON true/false:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

HttpGet get = ....; HttpClient client = ....; HttpResponse resp = client.execute(get); if (resp.getStatusCode() != 200) throw new IOException(...); JSONObject jsonResp = new JSONObject(EntityUtils.toString(resp.getEntity())); boolean success = jsonResp.getBoolean("result"); if (!success) throw new IOException(....); JSONObject authObject = jsonResp.getObject("payload");

---

Version JSON / http code:

Code:

---

1 2 3 4 5 6 7

HttpGet get = ....; HttpClient client = ....; HttpResponse resp = client.execute(get); if (resp.getStatusCode() != 200) throw new IOException(...); // on a déjà l'erreur ici ! JSONObject authObject = new JSONObject(EntityUtils.toString(resp.getEntity()));

---

Ok, je pense avoir pas mal de matière jusqu'à présent. Je reviendrais vers vous si besoin le moment venu ;)
Merci

nicroman:

Je ne remets pas en question le HTTPS et les désavantages de l'authentification basic sont nombreuses, car les identifiants même cryptées sont envoyées à chaque requête et en plaintext, et vulnérables aussi aux attaques CSRF (Cross-Site Request Forgery), par contre je ne vois pas l’intérêt de mettre en place du https dans un réseau local (sauf si le hacker est un employé de l’entreprise), cela dépend aussi de la sensibilité des données, qui va s'intéresser à un serveur Rest qui envoi la météo du jour. :)