DotNetOpenAuth RP falla detrás del dispositivo SSL

Question

Tengo problemas para que funcione un DNOA RP detrás de un dispositivo SSL (finaliza la conexión HTTPS del cliente y los HTTP de los servidores proxy inversos en el servidor web detrás de él).

El problema es que el RP es adivinar correctamente el punto final destinatario de la petición de entrada (ya que es no HTTPS para el momento en que llegue al servidor web) y comparando el punto final con el esquema en la URL return_to (que es HTTPS) - falla con la pila stacktrace a continuación. He acelerado un poco el código y no veo una forma de cambiar este comportamiento sin una compilación personalizada o una subclase no trivial. Ya estoy pasando la versión HTTPS del Reino y ReturnToUrl a OpenIdRelyingParty.CreateRequests(): esa parte funciona bien.

¿Es posible fusionar el esquema de destinatario detectado a HTTPS u omitir la comparación de esquema en una compilación DNOA estándar, o estoy parcheando una compilación personalizada mañana?

---

StackTrace:

ERROR DotNetOpenAuth.Messaging - 09 Jul 2010 00:11:39,450 - Protocol error: The openid.return_to parameter (https://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX) does not match the actual URL (http://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX&openid.ns=http://specs.openid.net/auth/2.0&openid.mode=id_res&openid.op_endpoint=XXX&openid.response_nonce=XXX&openid.return_to=https://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX&openid.assoc_handle=XXX&openid.signed=op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle&openid.sig=XXX&openid.identity=XXX&openid.claimed_id=XXX) the request was made with. 
at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String message, Object[] args) 
at DotNetOpenAuth.OpenId.Messages.IndirectSignedResponse.VerifyReturnToMatchesRecipient() 
at DotNetOpenAuth.OpenId.Messages.IndirectSignedResponse.EnsureValidMessage() 
at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary) 
at DotNetOpenAuth.Messaging.Reflection.MessageDictionary.Deserialize(IDictionary`2 fields) 
at DotNetOpenAuth.Messaging.Channel.Receive(Dictionary`2 fields, MessageReceivingEndpoint recipient) 
at DotNetOpenAuth.Messaging.Channel.ReadFromRequestCore(HttpRequestInfo request) 
at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestInfo httpRequest) 
at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse(HttpRequestInfo httpRequestInfo) 
at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse() 

Answer 1

DotNetOpenAuth ha incorporado en el soporte para dispositivos SSL cuando agregan estas cabeceras HTTP especiales a la petición HTTP enviada: X_FORWARDED_PROTO y/o HTTP_HOST. Cuando están presentes, la autodetección de la URL externa es correcta. Si puede configurar su dispositivo SSL para hacer esto, esa es probablemente la mejor opción.

La alternativa es llamar al OpenIdRelyingParty.GetResponse(HttpRequestInfo) en lugar de la sobrecarga que no requiere parámetros. Usted construye el HttpRequestInfo usted mismo usando la URL externa que sabe que es la real. Entonces la lógica de coincidencia de URL dentro de DotNetOpenAuth no fallará la solicitud.