Bonjour,

Je ne sais pas si c'est vraiment le bon endroit (c'est pas vraiment un site internet) mais bon.

Je me suis lancé depuis peu dans le développement d'applications mobile.

Après avoir appris comment manipulé une base de données en interne, j'apprends la manière externe et donc par conséquent les webservice.

Je comprends tout à fait le principe du service web qui retourne par exemple du XML ou JSON, et que c'est ce XML qui va servir pour l'application mobile.

Je veux faire une messagerie assez classique qui nécessite donc un compte; on s'inscrit, on peut envoyer un message à un membre etc.

Mais y a un truc qui me chagrine malgré tout; exemple je dois récupérer les messages du compte courant, je dois donc faire appel au webservice en lui passant un paramètre. Si je passe l'id du compte il renverra donc les messages du compte correspondant; mais voilà qu'est ce qui m’empêche d'envoyer un autre id que le mien ? (ou même d'accéder depuis le web au webservice et de lui envoyer un id différent)

Dans ce cas je récupèrerais les messages du compte en question (qui n'est pas le mien).

Grosso modo il faudrait que le service ne renvoie que les messages de la personne connectée au compte (j'avais pensé à rajouter l'email et le mot de passe dans la requête pour être sûr qu'il s'agit de la bonne personne)

Bref là j'avoue que j'arrive pas très bien à comprendre comment on peut éviter ce problème (c'est surement tout con comme d'habitude)

Merci d'avance.

Sur les WS autre que SOAP, en général tu passes une clé en paramètre de la requête, permettant de t'identifier. Ce que je recommande pour ne pas devoir balancer le mot de passe dans la requête (ça se verrait dans les logs), c'est un un hash unique par compte (que tu génères et enregistres comme bon te semble) :

http(s)://<server>/<clé>/<ressources>

Oui c'est ce qu'on vient de me proposer; générer un hash lors de la connexion, le stocker dans la base de données et le garder tout le long de l'application. Suffit ensuite de vérifier que le hash envoyé est bien celui correspondant au compte dans la DB.

Sinon, tu la requête HTTP, tu colles une basic auth, mais ça admet plus de contraintes dans la partie cliente.

Note que sur l'appli mobile de JVC, ils utilisent ça sous la forme :

http(s)://login:password@<server>/<ressources> (je n'ai pas en tête la trace générée dans les logs).