2010-07-09 3 views
7

У меня возникли проблемы с получением DNOA RP, работающего за устройством SSL (завершает клиентское HTTPS-соединение и обратное прокси-серверы HTTP за его веб-сервер).DotNetOpenAuth RP не работает с SSL-аппаратом

Проблема заключается в том, что RP неправильно угадать конечную точку получателя из входящего запроса (так как это не HTTPS к тому времени он попадает в веб-сервер) и сравнивая конечную точку со схемой на return_to URL (который является HTTPS) - он терпит неудачу с помощью stacktrace ниже. Я немного разбираюсь в коде, и я не вижу способа изменить это поведение без пользовательской сборки или нетривиального подкласса. Я уже передаю HTTPS-версию Realm и ReturnToUrl в OpenIdRelyingParty.CreateRequests() - эта часть работает нормально.

Возможно ли вымыть обнаруженную схему получателя на HTTPS или сравнить схемы пропусков на основе сборки DNOA, или я собираю сборку завтра?


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() 

ответ

8

DotNetOpenAuth имеет встроенную поддержку SSL устройств, когда они добавляют эти специальные заголовки HTTP для запроса пересылаемой HTTP: X_FORWARDED_PROTO и/или HTTP_HOST. Когда они присутствуют, автообнаружение внешнего URL-адреса является правильным. Если вы можете настроить свое устройство SSL для этого, это, вероятно, лучший вариант.

Альтернативой является вызов OpenIdRelyingParty.GetResponse(HttpRequestInfo) вместо перегрузки, которая не принимает параметров. Вы сами создаете HttpRequestInfo, используя обращенный к вам URL-адрес, который, как вы знаете, является реальным. Тогда логика соответствия URL-адресов внутри DotNetOpenAuth не подведет запрос.

+0

Perfect- спасибо! Я не контролирую устройство для одного из RP, но я определенно дам ему попробовать то, что я делаю (в настоящее время используется настраиваемая сборка с настраиваемым сравнением схем). – nitzmahone

+0

На основе кода https://github.com/DotNetOpenAuth/DotNetOpenAuth/blob/master/src/DotNetOpenAuth.Test/Messaging/HttpRequestInfoTests.cs, я считаю, что заголовок протокола должен быть HTTP_X_FORWARDED_PROTO –

Смежные вопросы