2010-07-12 7 views
42

Previamente le pedí a question sobre el uso del remote_api del motor de aplicación con openID, y la respuesta funcionó bien, tanto de forma segura como insegura. En algún momento poco después, sin embargo, algo en el motor de aplicación cambia, y la solución ya no funcionaba de forma segura - es decir, la siguienteSecure remote_api en el motor de aplicación con OpenID

remote_api_stub.ConfigureRemoteDatastore(app_id=app_id, path='/remote_api', auth_func=auth_func, servername=host, secure=True) 

dejó de funcionar (siempre volviendo 302), y que necesitaba para eliminar el argumento seguro de conseguir para que funcione El release of the 1.3.5 SDK prometió que los comandos Remote API pueden enviarse a través de HTTPS o HTTP, lo que me confundió, ya que tenía la impresión de que proporcionar el argumento 'secure = True' ya me había dado esto, basado en this discussion.

Mi sospecha es que fue el lanzamiento de esta función lo que provocó que el argumento 'seguro' dejara de funcionar. Así que la primera parte de mi pregunta - ¿Estaba ejecutando comandos remote_api de forma segura utilizando el argumento 'secure = True', antes del lanzamiento de 1.3.5?

Una vez que el hack de cookies dejó de funcionar de forma segura, probé la solución de Nick Johnson incluida en la misma pregunta, pero con esto tampoco pude proporcionar 'secure = True', obteniendo la misma respuesta 302.

¿Qué debo hacer para ejecutar remote_api de forma segura con openID? ¿Incluye 1.3.5 nuevas capacidades al respecto y cómo los uso? Cheers,

Colin

+0

¿Estás usando mi hack o hack de Nick, menos hacky? [http://blog.notdot.net/2010/06/Using-remote-api-with-OpenID-authentication] –

+0

He intentado ambas cosas, obtengo el mismo comportamiento, establecer 'secure = True' siempre da como resultado un 302 - eliminando 'seguro = verdadero' todo funciona bien. Tengo 'secure: optional' en app.yaml en el punto de entrada remote_api. Originalmente estaba usando tu hack exitosamente con secure = True, luego un día (alrededor del anuncio previo a la versión 1.3.5) 302 comenzó a ser devuelto. En este punto probé el truco menos hacky de Nick, pero también funcionó sin 'secure = True'. Estoy bastante seguro de que no fue un problema con la cookie, porque la misma cookie funcionó bien si 'secure = True' no estaba presente. – hawkett

+0

secure openid aún no funciona en el motor de la aplicación google. http://code.google.com/p/googleappengine/issues/detail?id=3586 – iamgopal

Respuesta

1

considera este

http://code.google.com/intl/en-US/appengine/articles/openid.html

ADVERTENCIA: en el momento de escribir estas líneas, OpenID no es compatible si su aplicación se ejecuta en modo seguro mediante HTTPS.

Saludos this en la última revisión en la liberación 1.3.7

def ConfigureRemoteDatastore(app_id, 
          path, 
          auth_func, 
          servername=None, 
          rpc_server_factory=appengine_rpc.HttpRpcServer, 
          rtok=None, 
          secure=False): 
    """Does necessary setup to allow easy remote access to an AppEngine datastore. 

    Either servername must be provided or app_id must not be None. If app_id 
    is None and a servername is provided, this function will send a request 
    to the server to retrieve the app_id. 

    Args: 
    app_id: The app_id of your app, as declared in app.yaml. 
    path: The path to the remote_api handler for your app 
     (for example, '/remote_api'). 
    auth_func: A function that takes no arguments and returns a 
     (username, password) tuple. This will be called if your application 
     requires authentication to access the remote_api handler (it should!) 
     and you do not already have a valid auth cookie. 
    servername: The hostname your app is deployed on. Defaults to 
     <app_id>.appspot.com. 
    rpc_server_factory: A factory to construct the rpc server for the datastore. 
    rtok: The validation token to sent with app_id lookups. If None, a random 
     token is used. 
    secure: Use SSL when communicating with the server. 

Entonces, ¿trató de que con el nuevo SDK?

+0

@eugene esta es la misma información que figura en el enlace proporcionado por @iamgopal en los comentarios del 21 de agosto. ¿Entonces Google desaprobó esta capacidad con 1.3.5? – hawkett

+0

creo que sí, tal vez deberíamos esperar 1.3.6 hoja de ruta para comprobarlo. – Eugene

+0

@eugene 1.3.7 está fuera.No creo que esta respuesta agregue nada que no estuviera presente en las preguntas/comentarios. – hawkett

Cuestiones relacionadas