WebService et session

CharlineCharline Membre
05:09 modifié dans Vos applications #1
Bonjour à  tous,

Je viens vers vous après moultes recherches concernant la mise en place d'une session entre un serveur web et l'iPhone. Sans résultat.

J'ai donc un site web qui tourne sur un serveur Apache. Il comporte une BDD Mysql. L'application iPhone est là  pour offrir une autre solution d'accès aux données de la base.
Moi et mon équipe sommes en train de la développer. Nous passons par le framework JSON pour les communications.
Aujourd'hui, tout marche bien, mais aucune sécurité n'est assurée : j'ai un formulaire d'identification, qui me dit que le couple identifiant / mot de passe est bon, mais ensuite toutes les requêtes se font à  la volée, sans vérification de l'identité.

Je m'étonne de ne pas trouver de solution "toute prête" concernant ce point, étant donné la multitude d'applications iPhone qui demandent un identifiant et mot de passe une et une seule fois (Leclerc Drive, Micromania, etc...)

Dans plusieurs threads, y compris dans ce forum, j'ai lu plusieurs fois qu'il était question de récupérer un token / jeton / ticket avec un identifiant de session. Cet identifiant est créé comment ? Par PHP ?
Il doit être envoyé à  l'appli iPhone tel quel ? J'imagine qu'une mise en place de SSL est nécessaire pour parfaire le tout ?

Merci d'avance pour vos lumières.
Cordialement,
Charline.

Réponses

  • AliGatorAliGator Membre, Modérateur
    05:09 modifié #2
    Il y a plusieurs solutions envisageables :
    1) Soit tu utilises SSL (donc en gros tu fais toutes tes requêtes vers ton WebService en HTTPS et pas en HTTP) et là  faut que ton site/serveur Web ait ce qu'il faut (certificat SSL)
    2) Soit tu utilises un mécanisme de session PHP en effet. C'est le même principe que les sessions d'un site web "classique", ça n'est pas spécialement spécifique à  l'iPhone.

    En gros tu utilises (info pour php, si tu utilises un autre langage faut trouver l'équivalent) la variable $_SESSION dans ton PHP pour stocker des informations qui sont passées de page en page dans ton site Web. C'est un peu comme les cookies, mais en plus flexible et géré côté serveur et non client.
    Ainsi dans tous tes PHPs de ton serveur, si tu vois que $_SESSION['login'] est vide, alors tu rediriges l'utilisateur vers une page de Login. Une fois que l'utilisateur a rentré ses identifiants, dans le PHP qui valide le formulaire de login tu vérifies si les identifiants+mdp sont bons et si oui tu fais un truc comme $_SESSION['login'] = $_POST['login']; (pour stocker le login passé par le formulaire dans la variable de session, qui va pouvoir ainsi perdurer de page en page, et en plus valider que tu es logué).

    Ainsi pendant toute la durée de la session (une session dans un navigateur web classique c'est tant que tu ne quittes pas le navigateur par exemple) tu pourras depuis n'importe quelle page accéder à  $_SESSION['login'] et ainsi vérifier si tu es loguée (et si oui c'est OK) ou pas (dans ce cas rediriger vers le formulaire de login si c'est un site que tu consultes via le Web, ou envoyer un code d'erreur genre "NotLoggedIn" s'il s'agit d'un WebService que l'utilisateur a cherché à  contacter sans être connecté avant).

    Pus d'infos sur le mécanisme de "sessions" en PHP

    Après il existe d'autres méthodes, comme utiliser un "token" retourné par le WebService qui te sert au login, et passer ce token à  chaque requête vers toutes les autres méthodes du WebService pour qu'il ne te réponde que si le token s'avère valide, mais dans l'idée ça revient un peu au même. Dans tous les cas cela se gère essentiellement côté serveur finalement (côté iPhone tu n'as qu'à  gérer le code d'erreur "NotLoggedIn" (en plus des autres cas d'erreur que peux te retourner ton WebService) et agir en conséquence dans ton appli si tu as ce cas (présenter un ViewController en modal qui demande le login/mdp par exemple, et refera appel à  ton WebService de login, etc)
  • CharlineCharline Membre
    05:09 modifié #3
    Merci pour cette réponse rapide !

    En fait l'appli iPhone n'implémente pas du tout de navigateur mais passe par un NSMutableURLRequest pour faire des requetes synchrones, le tout à  travers la variable POST. C'est donc des connexions ponctuelles, et je ne vois pas ben comment garder la session dans ce cas.

    Pour l'utilisation d'un token, je ne comprends toujours pas comment il peut être généré (par le serveur j'ai bien compris, mais comment ?). En sachant que même si c'est un id aléatoire ou quoi que ce soit, j'imagine qu'il ne faut pas le passer dans les requetes sans chiffrage ? Donc dans tous les cas, utiliser SSL ?
  • muqaddarmuqaddar Administrateur
    05:09 modifié #4
    Je dirai que tu te poses trop de questions.  ;)

    Qui gère la partie serveur ?
    C'est à  celui qui gère la partie serveur de créer les sessions une fois l'utilisateur connecté.

    Typiquement, on envoie le login et password et on génère la session si l'utilisateur est authentifié.

    Comme le disait Ali, cela marche exactement comme depuis un site Internet, y compris si tu n'utilises pas de WebView dans ton application mais NSURLRequest.




  • AliGatorAliGator Membre, Modérateur
    novembre 2010 modifié #5
    En effet c'est géré tout seul par NSURLRequest.

    Dans le Safari de ton iPhone une session correspond au temps pendant lequel Safari est "en vie" (et avec le multitâche c'est assez longtemps en général, sauf si le serveur prévoit des mécanismes d'expiration de session)
    Mais dans une application iPhone c'est pareil, car finalement NS(Mutable)URLRequest utilise le même mécanisme sous le capot que SafariMobile (ou plutôt SafariMobile utilise lui aussi des NSURLRequest/NSURLConnection et le WebKit et tout, et c'est le WebKit qui gère tout ça). En fin de compte même avec NSURLRequest la "session" au sens PHP dure également tout le temps que ton application reste "en vie".

    Au final, comme le dit muqaddar, tu te poses trop de question :D tout cela (persistance de la session, etc) est géré automatiquement côté iPhone, même si tu fais une première NSURLRequest à  ton WebService "login" d'un côté et que tu fais une NSURLRequest à  un autre WebService genre "getProductsList" du même serveur bien plus tard dans ton appli. Que ce soit dans une application iPhone, depuis SafariMobile sur ton iPhone, ou depuis Safari, Firefox ou Chrome sur ton Mac ou un PC, ça ne change rien, ça marche tout pareil. C'est au serveur de gérer cela (stocker l'état connecté ou non dans une variable de session, interdire l'accès aux WebServices si pas connecté, ...)



    Pour t'en convaincre tu peux faire 2 petites pages test en PHP, de mémoire ça donnerait un truc comme ça (à  valider ça fait longtemps que j'ai pas fait de PHP) :
    &lt;?php session_start();<br />$_SESSION&#91;&#39;login&#39;] = &quot;OK&quot;; ?&gt;
    &lt;?php session_start();<br />if ($_SESSION&#91;&#39;login&#39;]==&#39;OK&#39;) {<br />&nbsp; echo &quot;You have correctly logged in to the service so you have access to this page/WebService&quot;;<br />} else {<br />&nbsp; echo &quot;error: please login&quot;;<br />&nbsp; exit();<br />} ?&gt;
    &lt;?php session_start();<br />$_SESSION&#91;&#39;login&#39;] = &#39;KO&#39;; ?&gt;
    Et voilà , si tu vas (avec ton navigateur sur le Mac ou avec Safari sur ton iPhone) sur test.php tu verras qu'il te dit que tu n'es pas logué, si tu vas sur "login.php" il va te loguer et mémoriser cet état "logué" dans la session PHP, et si tu retournes sur test.php là  il te donnera accès, même alors que c'est une page (pouvant correspondre à  une méthode de WebService) différente... et si tu fais ces requêtes vers login.php et test.php via des NSURLRequests depuis ton application iPhone, tu verras que c'est pareil.

    Bon bien sur dans le cas réel login.php devra vérifier le login/mdp qui lui sont envoyés avant de passer $_SESSION['login'] à  OK, et test.php correspondra en réalité à  une méthode de ton WebService parmis d'autres, mais tu vois le principe.
  • muqaddarmuqaddar Administrateur
    05:09 modifié #6
    Ou bien, pour troller un peu, le même principe en Ruby :

    &nbsp; def login<br />&nbsp; &nbsp; if request.post?&nbsp; &nbsp; <br />&nbsp; &nbsp; &nbsp; if session[:user] = User.authenticate(params[:user_login], params[:user_password])&nbsp; &nbsp; <br />&nbsp; &nbsp; &nbsp; &nbsp; @response = { :success =&gt; &quot;OK&quot; }<br />&nbsp; &nbsp; &nbsp; else<br />&nbsp; &nbsp; &nbsp; &nbsp; @response = { :success =&gt; &quot;KO&quot; }&nbsp; &nbsp; &nbsp; &nbsp; <br />&nbsp; &nbsp; &nbsp; end&nbsp;  <br />&nbsp; &nbsp; &nbsp; respond_to do |format|<br />&nbsp; &nbsp; &nbsp; &nbsp; format.json { render :json =&gt; @response }<br />&nbsp; &nbsp; &nbsp; end&nbsp; <br />&nbsp; &nbsp; end<br />&nbsp; end


    Avec envoi de la réponse en JSON.
    Je ne comprends pas ces gens qui veulent mettre des $ partout.  :P
  • CharlineCharline Membre
    novembre 2010 modifié #7
    Bon ben en effet ... Je ne sais pas pourquoi je voulais absolument récupérer quelque chose du côté iPhone...

    Merci beaucoup à  vous deux 
    Ca me fait gagner un temps dingue x)

    A propos, si je veux récupérer ma session au prochain lancement de l'application, je suppose que je dois mettre un cookie ou quelque chose stocké du côté iPhone cette fois ?
  • AliGatorAliGator Membre, Modérateur
    05:09 modifié #8
    Les cookies aussi ils sont automatiquement stockés et gérés (et renvoyés au serveur) côté iPhone, rien à  faire de plus les NSURLRequests gèrent cela aussi automatiquement :)

    Si on veut un contrôle fin, par exemple tester par code Objective-C si un cookie est présent, ça reste tout à  fait possible (en demandant à  la classe NSHTTPCookieStorage) mais ça c'est quand on veut trifouiller dedans à  la main : normalement on a même pas besoin : NSURLRequest renvoie automatiquement ce qu'il faut quand le serveur le demande.

    Là  encore c'est côté serveur qu'il y a le boulot éventuel de décoder le cookie (en php c'est via $_COOKIE si j'ai bonne mémoire, un peu comme $_SESSION), côté iPhone rien à  faire de plus tout est déjà  prévu.

    Je te conseille fortement la lecture de ce Programming Guide dans la doc Apple qui explique tout en détail, mais finalement côté session comme côté cookie comme NSURLRequest renvoie tout seul tout ce qu'il faut tu n'as pas à  t'en soucier.
Connectez-vous ou Inscrivez-vous pour répondre.