DotNetOpenAuth RP échoue derrière l'appliance SSL

Question

Je rencontre des problèmes pour obtenir un RP DNOA fonctionnant derrière une appliance SSL (met fin à la connexion HTTPS du client et redirige le serveur HTTP vers le serveur Web derrière lui).

Le problème est que le RP est devinant correctement le point final du destinataire de la requête entrante (car il est pas HTTPS au moment où il touche le serveur Web) et en comparant le point final avec le schéma sur l'url return_to (qui est HTTPS) - il échoue avec la pile de pile ci-dessous. J'ai un peu spélé dans le code et je ne vois pas comment changer ce comportement sans une construction personnalisée ou une sous-classe non triviale. Je passe déjà la version HTTPS du domaine et ReturnToUrl à OpenIdRelyingParty.CreateRequests() - cette partie fonctionne très bien.

Est-il possible de fudger le schéma de destinataire détecté en HTTPS ou de comparer un schéma de saut sur une construction DNOA de stock, ou est-ce que je vais patcher une build personnalisée demain?

---

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 a un support intégré pour les appareils SSL lorsqu'ils ajoutent ces en-têtes HTTP spécifiques à la requête HTTP transmis: X_FORWARDED_PROTO et/ou HTTP_HOST. Lorsque ceux-ci sont présents, l'auto-détection de l'URL orientée vers l'extérieur est correcte. Si vous pouvez configurer votre appliance SSL pour ce faire, c'est probablement la meilleure option.

L'alternative est d'appeler OpenIdRelyingParty.GetResponse(HttpRequestInfo) au lieu de la surcharge qui ne prend aucun paramètre. Vous construisez le HttpRequestInfo vous-même en utilisant l'URL orientée vers l'extérieur que vous connaissez est la vraie. Alors la logique de correspondance d'URL dans DotNetOpenAuth n'échouera pas la demande.