Авторизуется только через webView после обновления #69

Обновился с версии 1.0.6.5 на 1.0.6.8, код не менял. Раньше авторизация проходила через сафари, все было ок. Сейчас решил обновиться, чтобы была возможность авторизовываться через vkApp. Всегда открывается web view Код:

The text was updated successfully, but these errors were encountered:

Так а vkApp в каком случае будет открываться?

Когда новую версию одобрят (когда-нибудь её должны одобрить)

А, сейчас получается только webView (и safari только при неудаче). Как только приложение одобрят (vkapp в смысле), мне уже нет необходимости менять код. Правильно?

Если у вас авторизация в ВК не основная, можно вернуть старый код:

Не совсем понял, как сделать так, чтоб в Safari вообще не уходило. Мне нужно только webView либо vk app, если она есть на устройстве. Как этого добиться?

Зачем запрещать уходить в сафари?

А зачем разрешать?

Это вообще странный подход - попеременно кидать юзера то туда, то сюда. Это сбивает его с толку.

Хотя мой вопрос продиктован вполне конретной причиной - после отмены авторизации в webView и попытке повторной авторизации оно переходит в Safari, а Safari ругается на bad page.

Я уже устал объяснять всем, что webview небезопасен для пользователя. В сафари пользователь может быть уже залогинен, и ему не придется снова вводить данные. Если выкидывает bad page, значит вы не на строили URL схему вашего приложения

Небезопасен или неудобен?

Неудобство - это вопрос предпочтений.

Безопасность - это уже серьезный вопрос.

В любом случае, хотелось бы определенности в поведении - либо так, либо эдак, но никак не "и так, и эдак". Сделайте тогда какие-нибудь параметры, что ли, чтобы можно было явно задавать.

Почему небезопасен: пользователь вводит данные своего аккаунта в какое-то непонятное приложение, которое, может быть, маскируется под страницу авторизации вконтакте.

SDK предусматривает следующее поведение по-умолчанию:

1. пользователь входит в приложение и нажимает кнопку авторизации вконтакте (приложение вызывает [VKSdk authorize:SCOPE])
2. проверяется наличие приложения вконтакте, способного провести авторизацию стороннего приложения
3. если такое есть, оно будет открыто
4. если такого не имеется, будет открыта webview с формой входа (проблема #64)
5. если на 4 шаге авторизация была неуспешна (например, пользователь отменил авторизацию), при повторной попытке авторизации будет открыт Safari с формой авторизации (разрешения доступа приложению, если пользователь авторизован)

При этом SDK имеет лицензию MIT, что означает для вас возможности безграничной модификации под свои нужды.

Почему небезопасен: пользователь вводит данные своего аккаунта в какое-то непонятное приложение, которое, может быть, маскируется под страницу авторизации вконтакте.

Я понимаю, что отговорка "но так делают многие" не очень серьезна по сути, но по факту так действительно делают многие. :)

Модификации, конечно, допустимы, но вряд ли это хороший подход - встает проблема синхронизации версий при последующих обновлениях базового продукта, т.е. SDK.

Мне представляется, что авторизация через webView - это своего рода хак, он продиктован не функциональностью продукта, а требованиями цензоров Apple, и сделан он для них, а не для пользователей и/или разработчиков. Например, в моем случае авторизация через соцсети модераторами, судя по всему, не проверяется, иначе бы приложение не прошло проверку. Боюсь, что навязывать этот "хак" всем использующим ваш SDK - наверное, не совсем правильно.

В любом случае, спасибо за разъяснения.

Мы и хотим от этого уйти, в общем-то. Собственно, я подумываю добавить флаг, с помощью которого разработчик сообщал SDK является ли авторизация вконтакте для приложения первоначальной

По поводу bad page в Safari - действительно, не обновил схему URL.

Но обнаружился еще один момент. Мне нужно, чтобы пользователь имел возможность входить под разными аккаунтами ВК. Поэтому по кнопке "выход" в своем приложении я делаю [VKSdk forceLogout] , и в этом случае при последующей попытке авторизации выдается webView с логином ВК.

В случае же, если пользователя перемещают в Safari, в котором он уже был залогинен ранее, у него нет возможности разлогиниться прямо в этот момент, поскольку Safari сразу же спрашивает "open this page in " и перенаправляет его обратно в приложение. Т.е., чтобы разлогиниться в приложении, пользователю нужно разлогиниться в ВК в Safari. Это очень большое неудобство на самом деле, и мало того, что это неудобство - многие пользователи вообще не сообразят, что же им делать в таком случае, а еще хуже, что все шишки будут сыпаться на разработчиков приложения. Плавали, знаем.

Сухой остаток - хочу авторизацию webView и только webView. :)

Поэтому стоит использовать и второй параметр: revokeAccess:YES

Предлагаю компромиссное решение.

Добавьте в логику определения, вызывать ли webView или Safari после неудачного логина, опциональный метод делагата. Кому нужно - вернет YES/NO. Тогда малой кровью можно обойтись и все сыты. :)

Поэтому стоит использовать и второй параметр: revokeAccess:YES

[VKSdk authorize:SCOPE revokeAccess:YES]

Можете сделать pull-request

[VKSdk authorize:SCOPE revokeAccess:YES]

В этот момент я не знаю, был ли до этого [VKSdk forceLogout] или не был. В случае с webView необходимость этого определяет сам SDK и все получается прозрачно.

revokeAccess позволит показать пользователю экран разрешения доступа, где он может разлогиниться

Этот экран будет показываться каждый раз, а не только тогда, когда предварительно вызывался [VKSdk forceLogout] . Это неудобно для пользователя.

Это нормально для пользователя

Это ненормально, поскольку мы используем OAuth, и это единственное применение VK SDK в приложении. Т.е. логин в ВК в нашем случае - это "сопутствующий" логин. У нас "главная" авторизация в приложении допускает возможность протухания сессии, поэтому пользователь в таких случаях логинится через ВК прозрачно и быстро. Заставлять его каждый раз вбивать реквизиты входа в ВК - неправильно и неудобно, теряется половина смысла OAuth.

Нет, не допускает. С недавнего времени все сессии вечные. У вас всё равно не получится прозрачного логина, потому что Safari будет блокировать быстрые переходы в приложение. Используйте revoke, и не беспокойтесь. Для пользователя же лучше нажать одну кнопку "Разрешить", и иметь возможность разлогиниться, если ему надо.

Я о нашей собственной авторизации говорю. :)

У вас всё равно не получится прозрачного логина, потому что Safari будет блокировать быстрые переходы в приложение.

Уже получается - вот прямо сейчас так и есть. Сафари не всегда спрашивает даже "открыть ли страницу в приложении", обычно он показывается на секунду и тут же перенаправляет обратно в приложение. А так он будет постоянно спрашивать разрешения, причем ведь это разрешение пользователь уже ему давал раньше, т.е. еще одна непонятка для него.