2011-01-02 14 views
8

El proceso de OAuth es:Determinar id de usuario en devolución de llamada oauth

  1. Para la autenticación OAuth, la aplicación (también conocido como cliente de OAuth) redirige al usuario a la authorize_url

  2. Esto redirige al usuario a OAuth Servidor web del servidor, donde el usuario concede acceso a la aplicación web a su cuenta

  3. El servidor OAuth redirige al usuario a la URL de devolución de llamada proporcionada por elAplicación(a.k.a oauth cliente). En este punto, la devolución de llamada provino del servidor OAuth y, por lo tanto, no tiene la identificación de la sesión ni el hash de la sesión. ¿Cómo es la aplicación para determinar a qué usuario se está solicitando la devolución de llamada post-oauth?

I, aunque la forma en que esto funciona es:

  1. Al redirigir usuario a la authorize_url anexar ciertos parámetros a la cadena de consulta ?id=xxx

  2. Cuando el servidor de OAuth redirige a callback_url proporcionado por el cliente , uno de los parámetros con el mensaje HTTP será el parámetro adjunto a la cadena de consulta en st ep 1.

Sin embargo, esto no parece funcionar para el servidor OAuth que estoy tratando de conectar.

¿Alguna sugerencia?

Respuesta

1

¿Qué quiere decir con "esto no funciona"?

El servidor no envía la parte de la consulta de nuevo? Debe codificar el estado en la url de devolución de llamada que proporciona al servidor oauth. Esto se puede hacer en la consulta o en la parte de la ruta. No veo ninguna razón por la cual esto no está funcionando?

¿Tal vez asume que tiene una única devolución de llamada genérica que se expande automáticamente con el estado? Hasta donde se sabe, este no es el caso.

EDITAR

que releer los documentos en la aplicación de Google:

You can specify a value for oauth_callback in an OAuthGetRequestToken request, 
to determine where Google redirects the user after they authorize your access 
request. The callback URL can include query parameters. The redirect will include 
the same query parameters, as well as the authorized request token, which your 
application must be able to parse. 

For example, when supporting multiple languages, you can include 
a query parameter that identifies the version of the application that a user is 
viewing. An oauth_callback value of "http://www.yoursite.com/Retrievetoken?Lang=de" 
would result in the redirect 
"http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE". 
Parsing the token and the language parameter ensures that the user is 
redirected back to the correct version of the site. 

SO (en contradicción con mi afirmación anterior) el servidor de OAuth activamente anexa información (& oauth_token = kkk) a tu URL La ficha debe ser la misma que recibió como resultado de "OAuthGetRequestTOken". ¿Esto no funciona para ti?

Por lo que yo entiendo ahora el servidor debe literalmente copiar todo lo que tiene en el callback_url y añadir el token que ha recibido de la llamada de servicio

¿Tiene un registro de lo exactamente su servidor de OAuth llamadas? ¿Quién es el proveedor de servicios? No me puedo imaginar que se esté perdiendo esta característica ...

+0

lol .... "esto no funciona" es vago :) – aiyer

+0

No recupero el parámetro que adjunto a authorize_url. – aiyer

+0

En su respuesta, ha indicado que debería codificar el estado en callback_url. Así que adjunté lo siguiente a callback_url: request_token = consumer.get_request_token (: oauth_callback => MY_CALLBACK + "? Id = xxx") Sin embargo, cuando el servidor oauth llama a la url de devolución de llamada, no obtengo "id" "como un parámetro. ¿Estoy haciendo algo mal, o el servidor oauth se implementó incorrectamente? – aiyer

4

Después de que el usuario haya verificado su token de solicitud (ingresando el nombre de usuario y la contraseña), debe obtener los parámetros oauth_token y oauth_verifier enviados de regreso, anexados a la devolución de llamada.

Si esto funciona, pero otros parámetros especificados en la devolución de llamada no estan incluidos en la devolución de llamada, entonces puede ser el caso de que el proveedor simplemente ignora la oauth_callback va a enviar en la etapa de solicitud de token.

Si este es el caso, el proveedor se referirá a una devolución de llamada predefinida, generalmente una que usted especificó al adquirir la clave de consumidor y el secreto.

Los proveedores de OAuth pueden ignorar las devoluciones de llamada enviadas durante el flujo de autorización (excepto para propósitos de firma). Algunos proveedores hacen esto para agregar una capa adicional de seguridad.

0

No veo el motivo por el que desea enviar una identificación del proveedor de OAuth al consumidor de OAuth. ¿Puedes explicar un poco más por qué necesitas hacer esto?

Si tiene una cookie de sesión asociada a sus usuarios, sabrá qué usuario está volviendo a usted (después del redireccionamiento), porque puede tener una sesión con él: será redirigido a través del navegador y devolverá su cookie.

Incluso si el OAuthProvider le envía su ID de usuario interno (lo cual es innecesario y muy poco probable, creo), ¿qué va a hacer con él? No coincidirá con su ID de usuario del sitio web interno, es un usuario totalmente diferente -id para el sitio del proveedor ... o tal vez no puede conseguir a su pregunta muy bien ....

saludos

+0

Creo que el problema es que los parámetros enviados junto con el parámetro oauth_callback se ignoran. Aunque puedo estar equivocado ... –

+0

Creo que su tercer punto es incorrecto: asume que después de que el servidor redirige al usuario de vuelta (a la url de devolución de llamada), el usuario no tendrá la cookie de sesión con él, y es por eso que piensa debería haber enviado una identificación de sesión en primer lugar y luego esperar recibirla nuevamente. Sin embargo, creo que no tiene sentido, porque el usuario será redireccionado a la url de devolución de llamada a través de su navegador y, por lo tanto, tendrá una sesión (que el consumidor haya configurado anteriormente). Es por eso que creo que su suposición es incorrecta, o simplemente no puedo obtenerla ... – middlehut

+0

Lyuben, tienes razón; Estaba teniendo el mismo problema. No me di cuenta de que la redirección ocurre desde su navegador. – Seth

1

puede utilizar parámetro de estado para eso, también tienen el servidor de autenticación para proporcionar datos de los usuarios del servicio basado en solo token de acceso

Cuestiones relacionadas