Це AccountManagerкорисно з наступних причин:
- По-перше, це збереження декількох імен облікових записів з різним рівнем доступу до функцій програми під одним типом облікового запису. Наприклад, у програмі для потокового перегляду відео можуть бути два імені облікових записів: одне з демонстраційним доступом до обмеженої кількості відео та інше з повним місячним доступом до всіх відео. Однак це не головна причина використання
Accounts, оскільки ви можете легко керувати цим у своєму додатку, не потребуючи цього вигадливого вигляду Accounts….
- Інша перевага використання
Accounts- це позбутися традиційної авторизації з ім'ям користувача та паролем щоразу, коли користувач запитує авторизовану функцію, оскільки аутентифікація відбувається у фоновому режимі, і користувач запитує свій пароль лише у певних умовах, які Я дістанусь до цього пізніше.
- Використання
Accountsфункції в android також усуває необхідність визначення власного типу облікового запису. Ви, напевно, натрапили на додатки, які використовують авторизацію облікових записів Google, що економить клопоти щодо створення нового облікового запису та запам'ятовування його облікових даних для користувача.
Accounts можна додавати самостійно через Налаштування → Облікові записи- Авторизацію користувачів між платформами можна легко керувати за допомогою
Accounts. Наприклад, клієнт може одночасно отримувати доступ до захищених матеріалів у своєму Android-пристрої та ПК без необхідності періодичних входів.
- З точки зору безпеки, використання одного і того ж пароля в кожному запиті до сервера дозволяє можливе підслуховування в незахищених з'єднаннях. Шифрування пароля тут недостатньо для запобігання крадіжки пароля.
- Нарешті, важливою причиною використання
Accountsфункції в android є відокремлення двох сторін, які беруть участь у будь-якому бізнесі, залежному від Accounts, так званого, аутентифікатора та власника ресурсів, без шкоди для облікових даних клієнта (користувача). Умови можуть здатися досить невиразними, але не здавайтеся, доки не прочитаєте наступний параграф… 😉
Дозвольте детальніше зупинитись на останньому на прикладі програми для потокового відео. Компанія A є власником бізнесу, що передає потокове відео, за контрактом з Компанією B, щоб надати своїм певним членам послуги преміум-потоку. Компанія B використовує метод імені користувача та пароля для розпізнавання свого користувача. Щоб компанія A визнала учасників преміум-класу B, одним із способів було б отримати їх список від B та використовувати аналогічний механізм узгодження імені користувача / пароля. Таким чином, автентифікатор і власник ресурсу однакові (компанія A). Крім зобов’язань користувачів запам'ятати другий пароль, дуже ймовірно, що вони встановили той самий пароль, що і профіль компанії B для користування послугами від A. Це, очевидно, не сприятливо.
Щоб усунути вищевказані недоліки, було введено OAuth. Як відкритий стандарт для авторизації, у наведеному вище прикладі OAuth вимагає, щоб авторизація була виконана Компанією B (автентифікатором), видавши маркер під назвою Токен доступу для правомочних користувачів (третьої сторони) та надавши Компанії A (власник ресурсу) лексема. Тож жоден маркер не означає ніякої придатності.
Я детальніше розповів про це та більше AccountManagerна своєму веб-сайті тут.
