›

Avis sur architecture d'application

MonsieurPaulMonsieurPaul Membre
dans Vos applications #1
Bonjour,

Je suis sur un petit projet d'application iOS pour afficher et éditer des données personnelles. Comme il faut que les données soient persistantes, et qu'il n'y en aura pas beaucoup, je comptais utiliser un fichier stocké localement.

Au fur et à  mesure que je lis ce forum, je me rends compte que je programme comme un cochon, alors pour ma prochaine app, j'ai envie de faire les choses correctement et commencer par dessiner son architecture, vous la soumettre et profiter de vos lumières.



[sharedmedia=core:attachments:1642]



Sa principale fonction est d'afficher et éditer des données personnelles. Comme il faut que les données soient persistantes, et qu'il n'y en aura pas beaucoup, je comptais utiliser un fichier stocké localement.

Je souhaiterais que le fichier soit encrypté et que l'app puisse être protégée par un mot de passe

De plus, l'app devrait être universelle avec gestion de l'orientation horizontale/verticale de l'écran.



Merci,



Paul

Réponses

  • MalaMala Membre, Modérateur
    #2
    Rien que pour l'effort intellectuel de poser les choses à  plat moi je dis... image/thumbsup.gif' class='bbc_emoticon' alt='' />



    La seule chose qui me choque c'est tes flèches d'interaction entre vues. Techniquement c'est le rôle des contrôleurs de s'appeler entre eux. Charge à  ceux-ci d'agir sur leurs vues respectives. Les contrôleurs constituent ainsi la colonne vertébrale de l'application.
  • yoannyoann Membre
    #3
    Déjà  tout ce qui est mot de passe et token d'auth server c'est à  stocker dans le Keychain et non NSUserDefault.



    Concernant le chiffrement (et non encryption) il y a déjà  toute les API native de l'iOS qui permettent d'activer le chiffrement de tes données dès que l'utilisateur à  un code de lock.



    Si tu veux aller plus loin (et avoir ton propre système de lock) à  toi de définir quelle méthode de chiffrement tu emplois. Pour la clef ce que je te recommande c'est de générer une clef aléatoire type UUID, de la chiffrer avec le code PIN de l'application et la stocker dans le keychain.



    De cette manière ton mécanisme d'authentification sera le suivant :
    1. Entrée du PIN de l'utilisateur
    2. Déchiffrement de la clef de chiffrement des données
    3. Déchiffrement des données
    4. Validation des données lu


    Si les données sont valide tu es authentifier et tes données sont déjà  accessible pour le reste des contrôleurs et sinon, retour en case départ.



    Lorsque l'utilisateur décide de changer son PIN, tu as simplement à  déchiffrer la clef stocké dans le trousseau puis la chiffrer de nouveau avec le nouveau PIN.
  • AliGatorAliGator Membre, Modérateur
    #4
    'Mala' a écrit:


    Rien que pour l'effort intellectuel de poser les choses à  plat moi je dis... image/thumbsup.gif' class='bbc_emoticon' alt='' />
    Je plussoie image/smile.png' class='bbc_emoticon' alt=':)' />
  • MonsieurPaulMonsieurPaul Membre
    #5
    Merci pour les commentaires.



    J'ai l'impression que même si l'app prévue est franchement basique, ce type d'exercice n'est pas complètement inutile. D'un point de vue psychologique, ça me rassure, j'ai l'impression que je sais par quel bout je peux prendre l'app pour la commencer (et la terminer). Et cela devrait me permettre de résister à  la tentation de mettre tout le code dans la première classe qui passe.



    Concernant le chiffrement, j'ai l'intention de me " limiter " aux API Apple. L'objectif est d'offrir une sécurité de base : pas d'accès direct pour n'importe qui avec l'iPhone en main, pas de données en clair dans un fichier facilement extractible par un explorateur de contenu iPhone.



    Concernant l'UUID, il semblerait qu'il faille arrêter de l'utiliser, ou dans mon cas, ne pas commencer à  l'utiliser.
  • yoannyoann Membre
    #6
    'MonsieurPaul' a écrit:


    Concernant l'UUID, il semblerait qu'il faille arrêter de l'utiliser, ou dans mon cas, ne pas commencer à  l'utiliser.




    Un UUID est un Universal Unique IDentifier. Tout le monde peut en utiliser (la commande uuidgen permet d'en générer depuis la ligne de commande). Ce qui est interdit c'est d'utiliser l'UUID du téléphone. Rien ne t'interdit d'en créer un.
  • AliGatorAliGator Membre, Modérateur
    #7
    Ne pas confondre UDID et UUID.

    - UUID = Universal Unique IDentifier, identifiant unique qui peut être généré par n'importe qui, via des outils en effet comme uuidgen ou CFUUIDCreate en C

    - UDID = Unique Device Identifier, qui est un identifiant unique du device, donc du téléphone (ou de l'iPad ou de l'iPod). Il se trouve être un UUID, mais qui a été généré une fois pour toute en usine par Apple, et donc chaque device a un UDID ce qui permet l'association UDID <=> device (et potentiellement device <=> personne) c'est là  tout le problème



    Rien ne t'empêche, plutôt que d'utiliser l'UDID associé au device, de générer un autre UUID que l'UDID, et de l'utiliser à  la place.
Connectez-vous ou Inscrivez-vous pour répondre.