#ios #amazon-web-services #aws-sdk #amazon-cognito
#iOS #amazon-веб-сервисы #aws-sdk #amazon-cognito
Вопрос:
Каждый раз, когда я запускаю aws: aws-sdk-ios-samples / CognitoSync-Sample, он генерирует новый уникальный identityId для моего устройства. Если я выключу приложение и перезапущу его, оно получит тот же identityId (из цепочки ключей). Но если я вхожу в систему с помощью Google и выхожу из системы, он выполняет AWSCognito.defaultCognito().wipe() — и функция очистки очищает связку ключей.
Затем, если я перезапущу приложение, я получу новый уникальный identityId.
При первом входе в систему с идентификатором Google или Facebook он использует этот вновь созданный identityId в качестве аутентифицированного identityId. Но после этого первого входа в систему всякий раз, когда я запускаю приложение, я получаю новый идентификатор, который затем выбрасывается при входе в систему и получении (теперь постоянного) идентификатора facebook или Google.
Должен ли я написать какую-то функцию «Очистки идентификатора идентификатора», чтобы перейти и удалить все эти старые идентификаторы? Как я должен ограничить количество идентификаторов? (каждый раз, когда пользователь запускает мое приложение и входит в систему, он выбрасывает новый неаутентифицированный идентификатор … навсегда зависающий в земле Cognito).
Я отредактировал метод AWSCognito.defaultCognito().wipe() в AWSCognitoService.m и удалил связку ключей, но это не помогло, потому что связка ключей после выхода из системы содержит аутентифицированный identityId из входа в Google.
Я думаю, что пользователи, не прошедшие проверку подлинности, не очень хорошо продуманы. Только во время тестирования с 3 идентификаторами я генерирую около дюжины идентификаторов в день, они помечаются как отключенные в пуле удостоверений.
Как мне их очистить? Или как мне прекратить их создание?
или я должен помнить свои собственные неаутентифицированные идентификаторы и пытаться каким-то образом восстановить с ними связь (если да, то как?)
Ответ №1:
Похоже, вы не хотите поддерживать вариант использования «Гостевой пользователь» или «Не прошедший проверку подлинности пользователь» в вашем приложении. Если это правильно, вы можете просто отключить «Поддержку неаутентифицированных удостоверений» для вашего пула удостоверений. В этом случае вашим пользователям всегда придется входить в систему с помощью какого-либо поставщика перед федерацией, и нежелательные неаутентифицированные удостоверения не будут сгенерированы.
Если вы хотите поддерживать неаутентифицированные удостоверения на устройстве, не следует удалять данные из хранилища устройства. Если вы не очистите, SDK удостоверится, что он использует кэшированный идентификатор удостоверения и не будет генерировать новый. В отличие от удостоверенных удостоверений, неаутентифицированные удостоверения по своей конструкции доступны только в том случае, если вы знаете идентификатор удостоверения.
Комментарии:
1. Я хочу, чтобы для некоторых функций приложения пользователь, не прошедший проверку подлинности, прошел проверку подлинности для других. Мой вопрос заключался в том, как избежать создания бесконечной серии идентификаторов identityId. Я хотел бы «повторно захватить» неаутентифицированный идентификатор, который использовался в последний раз. Но всякий раз, когда я выполняю аутентификацию, старый идентификатор unauth помечается как отключенный. Кэшированный идентификатор идентификатора сохраняется, но это identityId пользователя, прошедшего проверку подлинности. При тестировании это приводит к большому количеству идентификаторов identityId. В рабочей среде, где пользователи будут входить в систему один раз и не менять удостоверения, возможно, это не проблема.
2. Четан, спасибо. Я принимаю ваш ответ. Однако я узнал, что в смешанной среде с аутентификацией / аутентификацией невозможно избежать некоторых отключенных удостоверений (всякий раз, когда кто-то очищает устройство и повторно подключается к удостоверению, не прошедшему проверку подлинности). Кроме того, если вы выполняете слияние удостоверений, каждое слияние удостоверений создает отключенное удостоверение. Но на практике это создает разумное использование identityIds. При тестировании это создает их поток.