Ce n'est pas dans l'esprit iOS. Habituellement c'est l'OS ou l'utilisateur qui tue l'application à partir du bureau. Quitter brutalement un application ressemble un peu trop à l'effet d'un bug.
Perso je m'en sers quand il y a une incohérence entre ce que l'utilisateur envoi et des sécurité mises en place côté PHP.
Par exemple, si il passe à travers un proxy, change la valeur envoyée par une autre et que côté PHP, la vérification me dit qu'il y a un soucis, alors j'envoie un code erreur qui ferme l'application brutalement.
Entendu. Mais, après que l'utilisateur a quitté la voiture, il ne "ferme" pas l'appli ? Ce que je disais, c'est que tu mets du code sans une des méthodes qui sont appelées là et arrêter d'empêcher la mise en veille.
Moi, j'ai Navigon (GPS), qui empêche la mise en veille mais, lorsque je le quitte, si je ne suis pas en train de suivre un itineraire, l'appli cesse de tourner
Perso je m'en sers quand il y a une incohérence entre ce que l'utilisateur envoi et des sécurité mises en place côté PHP.
Par exemple, si il passe à travers un proxy, change la valeur envoyée par une autre et que côté PHP, la vérification me dit qu'il y a un soucis, alors j'envoie un code erreur qui ferme l'application brutalement.
La démarche peut sembler logique mais en fait il est totalement déconseillé de quitter l'application même si l'application n'a plus aucune raison de fonctionner. Pourquoi ? Parce que l'utilisateur ne comprend pas pourquoi ça s'arrête. En fait, dans ces cas là il faut présenter une erreur et bloquer l'utilisateur sur cet écran ou lui permettre de contacter le support par exemple.
Apple peut rejeter ton application si elle quitte automatiquement.
La démarche peut sembler logique mais en fait il est totalement déconseillé de quitter l'application même si l'application n'a plus aucune raison de fonctionner. Pourquoi ? Parce que l'utilisateur ne comprend pas pourquoi ça s'arrête. En fait, dans ces cas là il faut présenter une erreur et bloquer l'utilisateur sur cet écran ou lui permettre de contacter le support par exemple.
Apple peut rejeter ton application si elle quitte automatiquement.
J'comprends tout à fait, sauf que là , j'm'en sert quand un petit malin veut bidouiller les requêtes envoyer au serveur, à la recherche d'une faille.. j'prefère lui fermer l'application pour l'emmerder plutôt que de le laisser continuer ses tests comme il le souhaite.
Le jour où Apple me refuse l'application pour ça, j'ferai autrement
J'comprends tout à fait, sauf que là , j'm'en sert quand un petit malin veut bidouiller les requêtes envoyer au serveur, à la recherche d'une faille.. j'prefère lui fermer l'application pour l'emmerder plutôt que de le laisser continuer ses tests comme il le souhaite.
Le jour où Apple me refuse l'application pour ça, j'ferai autrement
S'il est possible de ton appli, de bidouiller les requêtes au serveur, tu as une mauvaise appli ou, au moins, un mauvais serveur !
Il faut que ton appli s'occupe de vérifier tous les données émis et d'empêcher les mauvaises ??? >:(
S'il est possible de ton appli, de bidouiller les requêtes au serveur, tu as une mauvaise appli ou, au moins, un mauvais serveur !
Il faut que ton appli s'occupe de vérifier tous les données émis et d'empêcher les mauvaises ??? >:(
C'est possible avec tout les applications ^^
Tu fais passer l'iPhone par un proxy, t'intercepte la requête envoyée, tu modifie les valeurs, tu l'as renvoi et tu regarde ce que te répond le serveur.. d'où l'obligation de vérifier les données reçues côté PHP.
L'élément 1 m'appartient bien (je peux donc le supprimer).
Si je modifie via le proxy, l'identifiant 1 par 2 et que le 2 ne m'appartient pas, je ne devrais pas pouvoir le supprimer... là je renvoi un code erreur qui ferme l'application.
Au delà de ça. Pour la suppression d'une data, tu ne mets pas l'identifiant en clair dans l'URL...
C'était un exemple
Quelque soit l'identifiant, en clair ou crypté, l'important c'est qu'il y ai toujours une vérification côté serveur.
Et tu attends une réponse du serveur vers l'utilisateur avec une demande pour sa vérification (handshake) avent d'exécuter la requête ?
Nan.
En gros :
Pour chaque requête, j'envoie le token de l'utilisateur + les paramètres dont j'ai besoin.
Côté PHP : je vérifie que mon token est toujours valide + je vérifie que l'action demandée est cohérente (par exemple, un utilisateur ne peut pas éditer/supprimer quelque chose qui ne lui appartient pas, etc etc)
C'est bien suffisant pour le type d'application que je fais ^^
Ah okay ! Non je pensais que c'était ta vraie façon de procéder.
Toute façon tu as entièrement raison. Tu peux mettre de la sécurité côté client mais si il y a bien un endroit où elle doit se situer c'est bien sur le serveur. Beaucoup plus complexe (si c'est bien fait), voir impossible, de by-passer une sécurité côté serveur.
Réponses
Fermer complètement l'application ?
Ce n'est pas dans l'esprit iOS. Habituellement c'est l'OS ou l'utilisateur qui tue l'application à partir du bureau. Quitter brutalement un application ressemble un peu trop à l'effet d'un bug.
On ne devrait jamais le faire. C'est pourquoi que tu le considères ?
J'avais effectivement lu que ce n'était pas conseillé.
J'ai un programme de domotique qui n'a aucune raison de continuer à tourner après certaines instructions.
D'autant plus que j'ai dû inclure l'instruction pour empêcher l'appareil de se mettre en veille automatiquement.
Perso je m'en sers quand il y a une incohérence entre ce que l'utilisateur envoi et des sécurité mises en place côté PHP.
Par exemple, si il passe à travers un proxy, change la valeur envoyée par une autre et que côté PHP, la vérification me dit qu'il y a un soucis, alors j'envoie un code erreur qui ferme l'application brutalement.
Du coup, dans une méthode qui arrive quand l'utilisateur mets ton appli en arrière-plan, tu arrêtes d'empêcher le mise en veille.
Le programme fonctionne en partie en voiture avec des instructions vocales (appareil en charge)
Je suis donc obligé d'éviter la mise en veille pour pouvoir donner des instructions, étant donné que je ne peux pas ouvrir l'application avec Siri.
Et une fois les tâches exécutées, il ne me partait pas utile de laisser tourner l'application.
Entendu. Mais, après que l'utilisateur a quitté la voiture, il ne "ferme" pas l'appli ? Ce que je disais, c'est que tu mets du code sans une des méthodes qui sont appelées là et arrêter d'empêcher la mise en veille.
Moi, j'ai Navigon (GPS), qui empêche la mise en veille mais, lorsque je le quitte, si je ne suis pas en train de suivre un itineraire, l'appli cesse de tourner
OK Merci
La démarche peut sembler logique mais en fait il est totalement déconseillé de quitter l'application même si l'application n'a plus aucune raison de fonctionner. Pourquoi ? Parce que l'utilisateur ne comprend pas pourquoi ça s'arrête. En fait, dans ces cas là il faut présenter une erreur et bloquer l'utilisateur sur cet écran ou lui permettre de contacter le support par exemple.
Apple peut rejeter ton application si elle quitte automatiquement.
J'comprends tout à fait, sauf que là , j'm'en sert quand un petit malin veut bidouiller les requêtes envoyer au serveur, à la recherche d'une faille.. j'prefère lui fermer l'application pour l'emmerder plutôt que de le laisser continuer ses tests comme il le souhaite.
Le jour où Apple me refuse l'application pour ça, j'ferai autrement
S'il est possible de ton appli, de bidouiller les requêtes au serveur, tu as une mauvaise appli ou, au moins, un mauvais serveur !
Il faut que ton appli s'occupe de vérifier tous les données émis et d'empêcher les mauvaises ??? >:(
C'est possible avec tout les applications ^^
Tu fais passer l'iPhone par un proxy, t'intercepte la requête envoyée, tu modifie les valeurs, tu l'as renvoi et tu regarde ce que te répond le serveur.. d'où l'obligation de vérifier les données reçues côté PHP.
Par exemple :
Pour supprimer un élément dans ma base de données, j'ai une requête du style : https://server.com/delete.php?id=1
L'élément 1 m'appartient bien (je peux donc le supprimer).
Si je modifie via le proxy, l'identifiant 1 par 2 et que le 2 ne m'appartient pas, je ne devrais pas pouvoir le supprimer... là je renvoi un code erreur qui ferme l'application.
Tu permets les requêtes comme ça sur ton serveur ? Sans vérification de l'identité de l'émetteur ? Je suis vraiment étonnée !
Qu'entends tu pars "sans vérification de l'identité de l'émetteur ?"
J'envoie le token de l'utilisateur à chaque requête.
Au delà de ça. Pour la suppression d'une data, tu ne mets pas l'identifiant en clair dans l'URL...
Et tu attends une réponse du serveur vers l'utilisateur avec une demande pour sa vérification (handshake) avant d'exécuter la requête ?
Et, en plus, comme dit Jérémy, ne mets jamais l'id en clair dans la requête >:(
C'était un exemple
Quelque soit l'identifiant, en clair ou crypté, l'important c'est qu'il y ai toujours une vérification côté serveur.
Nan.
En gros :
Pour chaque requête, j'envoie le token de l'utilisateur + les paramètres dont j'ai besoin.
Côté PHP : je vérifie que mon token est toujours valide + je vérifie que l'action demandée est cohérente (par exemple, un utilisateur ne peut pas éditer/supprimer quelque chose qui ne lui appartient pas, etc etc)
C'est bien suffisant pour le type d'application que je fais ^^
Ah okay ! Non je pensais que c'était ta vraie façon de procéder.
Toute façon tu as entièrement raison. Tu peux mettre de la sécurité côté client mais si il y a bien un endroit où elle doit se situer c'est bien sur le serveur. Beaucoup plus complexe (si c'est bien fait), voir impossible, de by-passer une sécurité côté serveur.