Soundcloud как провайдер Oauth: как заставить его подключаться только один раз

В настоящее время я внедряю потребительский сервис Oauth, который также будет использовать Soundcloud в качестве поставщика услуг Oauth. Но у меня возникла следующая проблема: в примере с Facebook или Twitter вы заходите туда, входите в систему, заполняете форму разрешения и снова перенаправляетесь в свое приложение. Если вы зайдете туда во второй раз и, учитывая, что вы уже вошли в систему, вы в основном пропускаете все шаги и мгновенно перенаправляетесь обратно. Это означает, что Facebook распознал, что вы уже дали разрешение этой сторонней службе, поэтому он не спрашивает вашего разрешения постоянно.

И это то, что происходит, когда я использую Soundcloud. По сути, каждый раз, когда я перенаправляю пользователя на конечную точку подключения Soundcloud Oauth, всегда появляется форма разрешения, хотя ранее я уже давал разрешение этой сторонней службе. Я вынужден нажимать «подключиться» каждый раз, что является перетаскиванием с точки зрения пользователя (сколько раз вы можете давать разрешение одному и тому же объекту). Мой вопрос: есть ли параметр, который я могу использовать, чтобы заставить soundcloud распознавать/проверять предыдущее разрешение от учетной записи пользователя на эту конкретную стороннюю службу? Или это реализация дизайна Soundcloud Oauth, и нам придется с этим жить?

Редактировать:

Возможно, это было непонятно, но каждый раз, когда я нажимаю «подключиться» в soundcloud, создается и доставляется новый токен доступа. Поскольку мое приложение использует этот токен доступа для идентификации своих пользователей, для меня не очень хорошо, что токен доступа обновляется каждый раз, когда я хочу войти в систему, что заставляет меня эффективно «подписываться» каждый раз. Подводя итог, я хочу получить ранее атрибутированный токен для своей учетной записи, чтобы я мог найти его в своей базе данных, идентифицировать его и войти в систему.

Я также ищу решение, которое не связано с сохранением состояния в клиенте, которое может быть очищено.


person ChuckE    schedule 25.01.2013    source источник


Ответы (1)


Что вы можете сделать, так это сохранить токен oauth пользователя в локальном хранилище и повторно использовать его в будущих сеансах. Вот что происходит на soundcloud.com.

Подробное объяснение:

Когда вы используете поток Connect, пользователь аутентифицируется SoundCloud (либо с помощью имени пользователя/пароля, Facebook Connect, либо уже существующего сеанса на soundcloud.com), а затем, когда это успешно, вашему приложению предоставляется токен oauth. для этого пользователя. Это передается на страницу обратного вызова, которая зарегистрирована для вашего приложения.

Этот токен — единственная часть информации, необходимая для того, чтобы пользователь «вошел в систему». Если срок действия токена не истек (по времени или из-за того, что пользователь вручную отозвал его), вы можете повторно использовать его в будущих сеансах.

Я думаю, что немного запутался в дизайне вашего приложения: где и как используется токен oauth? Я думаю, что вместо использования токена в качестве идентификатора, возможно, постоянная ссылка пользователя может быть лучше? Если у вас есть токен oauth, вы можете узнать постоянную ссылку, запросив api.soundcloud.com/me.

person nickf    schedule 27.01.2013
comment
под локальным хранилищем вы имеете в виду локальное хранилище html5 на стороне клиента? И я не уверен, что это то, что происходит в soundcloud, потому что они не используют свой рабочий процесс oauth, просто подписывают своего зарегистрированного пользователя, используя адрес электронной почты и пароль... - person ChuckE; 27.01.2013
comment
нет, оно использует тот же процесс oauth, что и любое другое приложение — я кое-что знаю об этом, так как я написал эту часть;) - person nickf; 28.01.2013
comment
хм... я не уверен, что мы говорим об одном и том же. Когда я захожу в soundcloud, я либо вхожу в систему с пользователем и паролем, либо с учетной записью facebook. В любом случае, Soundcloud идентифицирует меня либо по электронной почте, либо по уже сохраненному токену доступа, который возвращает Facebook. Теперь я не идентифицирую пользователей по электронной почте. Учетная запись soundcloud идентифицирует пользователя (токен доступа). Теперь каждый раз, когда я перенаправляю пользователя на soundcloud, я даю разрешение и каждый раз создаю новый токен доступа. Это отстой для выявления людей, у которых уже есть контент, созданный на моей платформе. - person ChuckE; 28.01.2013
comment
теперь это именно то, что я хочу сказать, создание действительного сеанса для уже существующего пользователя на стороне сервера, не прибегая к взлому javascript. Я хочу зайти в soundcloud, подключиться к стороннему приложению один раз и получить токен, и каждый раз, когда я возвращаюсь в soundcloud, они возвращают мне этот токен доступа (пока срок его действия еще не истек, что будет означать Придется обновлять). Это часть получения того же токена доступа, который я не получаю и хотел бы получить. - person ChuckE; 28.01.2013
comment
внес небольшое редактирование в вопрос, если у вас есть какие-то комментарии по этому поводу. - person ChuckE; 28.01.2013
comment
Спасибо за редактирование. Мой дизайн прост: мой пользователь идентифицируется только токеном доступа. Все остальное я могу загрузить из soundcloud. Для этого мне понадобится неизменяемый токен доступа, который будет обновляться только по истечении срока действия. Но проблема в том, что каждый раз, когда пользователь теряет сеанс и пытается войти в мое приложение, он подключается, нажимает кнопку и генерирует новый токен доступа, тем самым создавая новую учетную запись пользователя в моем приложении и делая ее информацию из предыдущий логин недоступен. Это то, чего я не вижу в Facebook (они всегда возвращают один и тот же токен). - person ChuckE; 28.01.2013
comment
Тем не менее мне нравится ваше предложение решения. Действительно, я могу взять все, что захочу, из конечной точки #me, чтобы идентифицировать моего пользователя (при условии, что это уникальное поле) и использовать его с постоянно обновляемым токеном доступа. Я все еще думаю, что токен доступа не должен обновляться каждый раз при подключении, но теперь это больше вопрос мнения о рабочем процессе Oauth, а не сопротивления разработке. :) Так что я приму ответ. - person ChuckE; 28.01.2013
comment
Теперь я действительно хотел бы избежать перехода на страницу подключения каждый раз при входе в систему и сделать ее более автоматической в ​​стиле facebook (если уже есть действующий сеанс и предыдущее разрешение, вы вряд ли его увидите). Я просто думаю, что конечный пользователь выиграет от того, что у него будет на один щелчок меньше для входа в систему, а soundcloud выиграет от того, что его больше используют в качестве решения для единого входа, что сделало бы его беспроигрышным сценарием :) Не стесняйтесь спорить. . - person ChuckE; 28.01.2013
comment
Ха-ха, тут без аргументов. Я все еще не уверен, почему вы не можете хранить клиентский токен oauth локально (на клиенте)? Когда они снова заходят (хотя и с тем же компьютером + браузером), вы можете обнаружить (с помощью Javascript), что они уже вошли в систему, и им не нужно снова показывать всплывающее окно подключения. - person nickf; 29.01.2013
comment
то же самое верно, если сеанс все еще действителен. Тем не менее, локальное хранилище — это решение для работы в автономном режиме. Но моя точка зрения остается в силе. - person ChuckE; 30.01.2013