(Réglé) Transmettre des infos dans toute l'application
Bonjour,
J'ai un module de connexion, et j'aimerais qu'une fois que l'utilisateur soit connecté, je puisse faire transiter ces identifiants de connexion dans toute l'application, mais que ces identifiants soient détruits lors de la fermeture de l'application (en quelque sorte enregistré dans une mémoire cache).
Je ne me vois pas transmettre 2 strings à chaque fois sur toutes mes vues, je pense que c'est un peu prise de tête et potentiellement pas forcément très sécurisé (vu que je pense qu'il est possible de récupérer les datas lors d'un changement de vue), alors je voulais savoir s'il existait autre chose s'il vous plait ?
J'ai bien pris note des NSUserDefaults qui n'est pas sur du tout pour faire transiter ce genre d'info, et du KeyChainItemWrapper, mais ce dernier conserve les identifiants même quand l'application est quittée donc ce n'est pas ce que je veut dans l'absolu.
L'un de vous saurait il m'aiguiller sur la manière de faire s'il vous plait ?
Merci d'avance.
Bonne journée.
Réponses
Sauf que ça va envoyer qu'aux objects qui sont abonnés, si tu vas sur des nouveaux écrans et que tu crées des nouvelles instances de nouveaux VC du coup la notif aura déjà été envoyée et ils l'auront loupée.
Si tu veux pouvoir accéder à des données à tout moment depuis n'importe quel endroit de l'application, c'est plutôt une SharedInstance (je te laisse faire une recherche on en a parlé 36000 fois)
Sinon, transmettre à chaque fois tes 2 strings login/mdp ça fait peur... pourquoi t'as besoin de ça, tu les renvoies tous les 2 à chaque envoi de requête ?! Si oui bonjour la sécurité :-S
C'est très étrange de ne pas vouloir stocker ce genre d'info dans le keychain... pourquoi vouloir les supprimer ?
D'accord donc NSNotificationCenter c'est pas ce qu'il me faut.
Je t'explique mon architecture brièvement
Détail d'une offre
Ajouter une offre
Favoris de l'utilisateur
Connexion
Profil de l'utilisateur
En fait une fois sur Connexion quand il est connecté cela le renvois sur la vue Profil.
Donc en fait je voudrais que s'il retourne sur la page Connexion, s'il voit que les identifiants sont non nuls, il passe immédiatement à la vue Profil.
Dans le détail de l'annonce j'ai besoin de récupérer des infos relatives à l'utilisateur (adresse mail, téléphone). J'ai également besoin d'ajouter un favori pour le compte de l'utilisateur
Muq: en fait si tu veut j'ai 2 options, une option "normale" et une "mémoriser mes identifiants de connexion", et cette 2nde mémorise même une fois l'appli quittée alors que pas la 1ère
Ah oui et pourquoi donc ?
Bon on a déjà eu cette discussion mais le pass est crypté en MD5, donc c'est toujours mieux que de l'envoyer en clair, même si ça reste pas très secure.
Regarde tous les cours de sécurité qui trainent sur Google & co. Faut passer par un service d'authent que tu n'appelles qu'une seul fois et te retourne un token, valable pour quelques temps. Et tu utilises ce token pour les requêtes ensuite.
En transmettant le login/pass à chaque fois tu augmentes les chances que qqun qui écoute ce qui passe sur le réseau récupère ce login/pass (ou son MD5 mais ça change pas grand chose) et puisse le réutiliser.
Alors qu'avec un token, si jamais il se fait intercepter, au moins comme le token expire, au bout de qques heures il ne pourra plus être utilisé.
Et en plus, ça décharge toutes les tâches de lookup du service d'authentification (potentiellement coûteuse s'il y a une base d'utilisateurs déportée sur le serveur, type LDAP ou autre)
C'est comme quand tu vas dans un festoche, si tu as à présenter ta carte d'identité à chaque fois, d'une part tu risques de la perdre à force de la sortir et re-ranger, en plus c'est long à vérifier toutes les infos de carte d'identité de chacun à l'entrée du festoche, donc à la place une fois que ta carte d'identité a été vérifiée une fois, on te file un bracelet ou un tampon qui dure juste pendant le festoche et ne sert plus à rien après. Bah là c'est pareil.
Je te (re)conseille vivement de lire un peu de littérature sur la sécurité, c'est quand même pas anodin comme problème.
Intéressant ce concept de token, je ne connaissais pas.
J'essaierai de m'en souvenir le jour venu.
C'est quelle techno (https ?) ?
Rien à voir avec http ou https.
Un token est un ID que ton serveur crée (genre ty6uy798hyf6) et renvoie au client, pourqu'il le renvoie à son tour au serveur à la requête suivante. C'est une sécurité supplémentaire.
OK, mais quelle techno gère les token (via quelle techno le server sait que tel token est autorisé sur tel période). C'est le webservice qui gère ça ? Donc, du php + sql ?
C'est la techno serveur (php, rails, ruby...).
En gros :
1) le client envoie une requête pour se connecter genre au WS "/connect.php" par exemple, avec son login & mdp (bien sûr il faut déjà absolument que cet échange soit en HTTPS pour que les échanges entre le client et le serveur soient chiffrés et ne soient pas interceptables par l'extérieur). Une fois la requête envoyée, il peut totalement oublier le login et le mot de passe (à la limite il mémorise le login pour un mode "Se souvenir de moi", mais il oublie le mot de passe en tout cas ne le stocke pas dans des variables de l'app)
2) Le serveur reçoit la requête, fait un aller/retour dans la base de données des utilisateurs (qui est peut-être sur le même serveur que ton WebService mais peut aussi être potentiellement distante, genre sur un serveur LDAP dédié) pour vérifier les credentials (login, mot de passe, droits spécifiques, etc)
3) Si l'authentification est acceptée, le serveur génère un token (une chaà®ne aléatoire générée via un générateur pseudo-aléatoire quelconque), le mémorise localement (par exemple dans les variables de session, donc dans $_SESSION si tu fais du PHP), et le renvoie au client
4) Le client reçoit le token et le garde en mémoire. Il va à partir de maintenant utiliser le token lors de toutes requêtes suivantes qu'il enverra à son WebService (par exemple en envoyant le token dans les paramètres GET de chaque requête, ou le plus souvent plutôt dans un header "Authorization: Bearer mytoken123" de chaque requête)
5) A chaque fois qu'une requête est envoyée au WebService, le WS peut comparer le token envoyé dans les headers avec celui qu'il a mémorisé dans $_SESSION, et considérer que l'authentification est bonne s'ils sont identiques, mauvaise s'ils sont différents.
6) Au bout d'un certain temps " soit un temps absolu depuis la génération du token, soit plus généralement un temps depuis la dernière requête reçue avec ce token, tout cela est à définir par l'auteur du WebService " le WS considère que le token a expiré et en demande un nouveau à l'utilisateur. L'utilisateur doit alors se reconnecter avec ses identifiants et mdp pour obtenir un nouveau token.
(ça techniquement il suffit à chaque requête de comparer la date actuelle avec la date de la dernière requête que tu auras pris soin de stocker dans $_SESSION à chaque appel au WS, et si l'écart entre date actuelle et dernière requête est supérieur à la durée d'expiration tu invalides le token et renvoies une 401)
Tu observes souvent ce comportement sur pas mal de sites web, où ils te disent "votre session a expiré, veuillez vous reconnecter", bah ça vient de là
Les avantages :
- Le serveur n'a pas à revérifier tes credentials / login/mdp à chaque requête, ce qui est potentiellement coûteux. Donc ca accélère les échanges
- Tu ne renvoies pas tes login/pass en clair à chaque requête, réduisant ainsi le risque de te les faire intercepter si jamais la communication client/serveur est corrompue et lue par un curieux. Au pire le curieux récupère le token, mais pas tes login/pass d'origine, donc ne pourra plus utiliser ce token une fois qu'il sera expiré.