DotNetOpenAuth RP nie działa za urządzeniem SSL

Question

Mam problem z uzyskaniem DNOA RP działającego za urządzeniem SSL (kończy połączenie HTTPS klienta i proxy odwrotne HTTP z serwerem sieciowym za nim).

Problem polega na tym, że RP jest nieprawidłowo zgadywania końcowego odbiorcy z żądania przychodzącego (ponieważ jest to nie HTTPS zanim dotrze on do serwera WWW) oraz porównując końcowy ze schematem na URL return_to (który jest HTTPS) - kończy się niepowodzeniem z poniższym stosem stacków. Spalunkowałem trochę w kodzie i nie widzę sposobu na zmianę tego zachowania bez niestandardowej kompilacji lub nietrywialnej podklasy. Już przekazuję wersję HTTPS Realm i ReturnToUrl do OpenIdRelyingParty.CreateRequests() - ta część działa dobrze.

Czy można wykombinować wykryty schemat odbiorcy do HTTPS lub pominąć porównanie schematu w magazynie DNOA, czy też poprawiam niestandardową kompilację jutro?

---

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 posiada wbudowane wsparcie dla urządzeń SSL kiedy dodać tych specjalnych nagłówków HTTP do żądania HTTP przekazywanych: X_FORWARDED_PROTO i/lub HTTP_HOST. Gdy są obecne, automatyczne wykrywanie zewnętrznego adresu URL jest poprawne. Jeśli możesz tak skonfigurować urządzenie SSL, jest to prawdopodobnie najlepsza opcja.

Alternatywą jest wywołanie OpenIdRelyingParty.GetResponse(HttpRequestInfo) zamiast przeciążenia, które nie przyjmuje parametrów. Sam zbudujesz HttpRequestInfo, używając adresu URL skierowanego na zewnątrz, który, jak wiesz, jest prawdziwy. Wtedy logika dopasowywania adresów URL w DotNetOpenAuth nie zawiedzie żądania.