10
votes

Comment identifier un appareil iOS uniquement

Dans mon application actuelle, je dois laisser l'utilisateur à se connecter à partir de différents périphériques iOS à leur compte. Actuellement, je fais une authentification de l'utilisateur à partir d'une valeur de jeton. Mais afin de prendre en charge plusieurs appareils de connexion, je dois trouver une autre façon de le faire.

Ainsi, j'ai pensé à enregistrer des appareils uuid avec jeton pour authentification + sécurité. Ensuite, je viens de savoir que je ne peux pas utiliser uuid , je dois plutôt utiliser identifiantforvendor qui peut toujours fournir des informations utilisateur ou périphérique toujours.

Donc, quelqu'un peut-il suggérer la meilleure façon de réaliser cette fonctionnalité de connexion à périphérique multiples pour le même compte d'utilisateur dans iOS?


0 commentaires

3 Réponses :


0
votes

Vous devez utiliser les méthodes standard de créer une UUID. Apple ne veut pas que vous suiviez des périphériques.

CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault);
NSString *uuidString = (NSString *)CFUUIDCreateString(NULL,uuidRef);
CFRelease(uuidRef);


0 commentaires

9
votes

Comme vous le savez déjà à l'aide de l'UUID de l'appareil n'est pas autorisé, vous pouvez générer votre propre UUID et le stocker sur les périphériques 'UserDefaults.

Utilisation de l'identifiantFendor n'est pas fiable à 100%, car fonctionne sur IOS6 et plus et les utilisateurs ont la capacité de vous désactiver de vous le donner, ce qui en fait un mauvais choix.

Voici un code que j'ai copié les internets il y a parfois et toujours l'utiliser jusqu'à ce que Aujourd'hui, vous allez essayer de trouver la source et mettra à jour ma réponse dans un peu. Edit: Source < p> Cela générera et stockera un UUID pour vous dans UserDefault: xxx

et chaque fois que vous devez lire l'UUID généré: xxx

Maintenant, vous avez le choix d'ajouter l'ID de votre propre utilisateur à cela aussi, vous pourrez également savoir ce que UUID est lié à quel utilisateur ..

Ceci est juste un croquis approximatif de la façon dont il devrait fonctionner


9 commentaires

Je suppose que si un utilisateur réinstalle l'application, une nouvelle UUID sera créée?


Cela ne semble pas utile. Comment quelqu'un aimerait-il que la société de carte de crédit trace une activité frauduleuse à l'appareil si l'ID peut changer?


@Sinaesthétique Ce n'est pas la portée de cette solution, je ne suis pas sûr de ce que vous voulez dire, mais il y a un milliard de façons de suivre l'activité au téléphone, il n'est tout simplement pas ouvert aux développeurs tiers, je suppose que c'est juste accessible via Apple, ou NSA;), mais si vous voulez dire l'UDID de l'appareil, cela ne change jamais!


Les applications financières doivent être capables d'identifier de manière unique l'appareil et d'envoyer ces informations au processeur (par exemple, MasterCard). Apple rend l'UUID inaccessible et l'alternative ApplicationID qu'elles fournissent peuvent changer si l'utilisateur désinstalle et réinstalle l'application de la même manière que l'application générant son propre code-- afin que cela ne puisse donc pas vraiment identifier aucun appareil. Je ne suis pas combatif, j'essaie simplement de résoudre ce problème aussi.


@Sinaesthétique Je comprends votre point, mais ils ne s'appuient pas seulement sur les informations de périphérique comme le seul moyen d'identifier l'utilisateur, rappelez-vous qu'ils doivent enregistrer le périphérique lors de l'installation, qui relie l'UDID généré actuellement sur leur nom d'utilisateur / compte, si le L'utilisateur réinstalle l'application, ils doivent toujours s'inscrire à nouveau et relier l'UDID nouvellement généré sur le nouveau compte et, dans leurs journaux internes, ils auront toujours tous les antécédents de transaction avec un UDID que ce client ait jamais utilisé. Espérons que vous répondez à votre question ?


OK Imaginez le scénario: un seul appareil pouvant prendre en charge plusieurs utilisateurs via leur nom d'utilisateur / mot de passe. Je suis Mastercard. J'ai une transaction qui semble être frauduleuse. J'ai besoin de savoir quel utilisateur avec quel appareil (c.-à-d. Lane) sur lequel cette transaction a été effectuée. Avec ce que vous dites, je suis capable de voir que l'utilisateur a fait la transaction sur le périphérique A23423 qui est également appelée dispositif A99999 et AB3243 (il a été réinstallé deux fois). Qu'est-ce que l'identifiant de périphérique généré signifie pour moi? Comment puis-je pouvoir prouver quel appareil physique a eu lieu la transaction? Qu'est-ce qu'il faut arrêter quiconque d'entrepoofing cet identifiant?


En d'autres termes, comment puis-je prouver que Alex a effectué une transaction sur le téléphone de Jake qui lui a été donné par John?


L'appareil n'est pas également appelé A99999 , il était connu sous le nom de THOS A99999, l'appareil disposera d'un seul et d'un seul courant UDID à la fois. votre scénario n'a pas de sens pour moi et n'a rien à voir avec UDIDS


En ce qui concerne identifiantforvendor , la réponse indique "les utilisateurs ont la capacité de vous désactiver de vous le donner." Je ne crois pas que ce soit correct. identifiantforvendor est toujours valide. Apple Docs ne dit pas le contraire. Voir https://stackoverflow.com/a/12698912



2
votes

Tout d'abord, les directives de développeur Apple interdisent / décourager l'utilisation de l'IDFA pour suivre l'utilisateur dans le but d'afficher des publicités ciblées (et quelques autres choses). Les lignes directrices permettent clairement au développeur d'utiliser l'IDFA pour identifier le périphérique à des fins de sécurité. Citant les lignes directrices Apple

PublicitéTrackingenabled (fort>

une valeur booléenne qui indique si l'utilisateur a un suivi de la publicité limitée. (lecture seule)

@ Propriété (nonatomique, readonly, getter = isadvertisingtrackingenabled) Bool PublicitéTrackingenabled

Discussion

Vérifiez la valeur de cette propriété avant d'effectuer n'importe quel suivi publicitaire. Si la valeur est non, utilisez l'identifiant publicitaire uniquement aux fins suivantes: Capuppers de fréquence, événements de conversion, estimation du nombre d'utilisateurs uniques, de détection de sécurité et de fraude, et de débogage.

Vous pouvez utiliser IDFA de l'appareil à des fins de connexions de plusieurs périphériques. Le flux serait un peu comme celui-ci:

  1. L'utilisateur se connecte au serveur à l'aide du périphérique A, le serveur envoie un jeton qui est stocké sur l'appareil dans nsuserdefault . L'application stocke également l'IDFA sur l'appareil dans nsuserdefault

  2. Ce jeton sera utilisé pour créer une chaîne cryptée qui contiendrait l'IDFA. (chiffrer l'IDFA à l'aide du jeton) La valeur cryptée serait transmise au serveur dans chaque demande avec l'IDFA d'origine.

  3. Le serveur utiliserait alors l'IDFA et le jeton associé à celui-ci (le serveur stockerait bien sûr l'IDFA correspondant à chaque jeton) pour obtenir la valeur cryptée de l'IDFA et la correspondre à la valeur cryptée reçue. dans la demande. Le fait de faire cela est de faire en sorte que personne ne puisse pirater sur votre serveur car le jeton ne serait pas visible pour personne, mais l'application (vous pouvez même stocker le jeton dans un format crypté afin d'augmenter le niveau de sécurité). < / p>

  4. Chaque fois qu'une demande est envoyée au serveur, la valeur de l'IDFA stockée sur l'appareil dans nsuserdefault serait comparée à l'IDFA actuelle.

  5. Si vous trouverez une inadéquation, l'IDFA actuel serait d'abord mis à jour sur le serveur, puis après avoir obtenu la confirmation de la mise à jour réussie, l'application remplacerait l'IDFA stockée sur l'appareil dans nsuserdefaults Avec l'actuel (et l'entreprise fonctionne alors comme d'habitude).

    Vous pouvez également éviter l'étape 3,4 et stocker IDFA sur l'appareil dans NSUserDefault mais dans lequel l'utilisateur peut se connecter au serveur sur la réinitialisation de l'IDFA.

    juste confirmer, la cartographie du jeton vers l'IDFA serait beaucoup à un.

    J'espère que cela aide, commenter tout ce qui n'est pas clair / ne satisfaisant pas le cas d'utilisation.


0 commentaires