Odrzucenie powiązania, ponieważ deserializacja zakodowanego uchwytu nie powiodła się. DotNetOpenAuth - openid, dotnetopenauth

Pracuję na próbkach DotNetOpenAuth i wdrażam dostawcę OpenID i stronę ufającą.

Zasadniczo jest on bardzo podobny do dostarczonych próbek DotNetOpenAuth, z wyjątkiem tego, że używam MVC 4, a więc Razor, a zatem nie używam IdentityEndpoint kontrola stosowana w próbce. (Piszę nagłówki dostawcy w częściowym widoku). Obsługiwany także w IIS 7.5.

Docieram do punktu, w którym użytkownik się loguje, a OP przekierowuje z powrotem do strony zależnej, która otrzymuje następujący błąd z dzienników:

DotNetOpenAuth.Messaging.ProtocolException: Brak klucza deszyfrującego dla wiadra „Uchwyt https: // localhost / dnoa / association_handles” „3tg1”
at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol (warunek boolowski, String unformattedMessage, Argument Object [])
at DotNetOpenAuth.Messaging.DataBagFormatterBase`1.CalculateSignature (Byte [] bytesToSign, String symmetricSecretHandle)
za....

Nie jestem pewien, czy to pomaga, ale dwa nagłówki poprzedzające błąd to:

Signing these message parts:
claimed_id: http://www.sampleOpenIDProvider.com/user/justpartofthecrowd
identity: http://www.sampleOpenIDProvider.com/user/justpartofthecrowd
assoc_handle: he9m!IAAAAD43Voo3-zQng-ZVSKb9ryFVSIKDLJj4Ph_I9W64ypFCQQAAAAFlZWUQzOJQfO70Pvud2a--auCE7HKkFjBM45HXlpJixLEmtdgd8YPBMckvUFnIPqHBbaAk7mkhI8lDVPoKekUW
op_endpoint: http://www.sampleOpenIDProvider.com/OpenId/Provider
return_to: http://www.samplemobilephonecompany.com/User/Authenticate?ReturnUrl=Index&dnoa.userSuppliedIdentifier=http%3A%2F%2Fwww.sampleOpenIDProvider.com
response_nonce: 2012-12-03T23:59:05ZCqMBPIFL
Base64 representation of signed data: Y2xhaW1lZF9pZDpodHRwOi8vd3d3LnNvbGZ5cmUtaWQuY29tL3VzZXIvcmFscGhza2kKaWRlbnRpdHk6aHR0cDovL3d3dy5zb2xmeXJlLWlkLmNvbS91c2VyL3JhbHBoc2tpCmFzc29jX2hhbmRsZTpoZTltIUlBQUFBRDQzVm9vMy16UW5nLVpWU0tiOXJ5RlZTSUtETEpqNFBoX0k5VzY0eXBGQ1FRQUFBQUZsWldVUXpPSlFmTzcwUHZ1ZDJhLS1hdUNFN0hLa0ZqQk00NUhYbHBKaXhMRW10ZGdkOFlQQk1ja3ZVRm5JUHFIQmJhQWs3bWtoSThsRFZQb0tla1VXCm9wX2VuZHBvaW50Omh0dHA6Ly93d3cuc29sZnlyZS1pZC5jb20vT3BlbklkL1Byb3ZpZGVyCnJldHVybl90bzpodHRwOi8vd3d3LnNhbXBsZW1vYmlsZXBob25lY29tcGFueS5jb20vVXNlci9BdXRoZW50aWNhdGU/UmV0dXJuVXJsPUluZGV4JmRub2EudXNlclN1cHBsaWVkSWRlbnRpZmllcj1odHRwJTNBJTJGJTJGd3d3LnNvbGZ5cmUtaWQuY29tCnJlc3BvbnNlX25vbmNlOjIwMTItMTItMDNUMjM6NTk6MDVaQ3FNQlBJRkwK
Signature: kw4f92CpwFbXgUkLs+Pf+5cFrtEzmE9KpxHgTYwi1tQ=

i

After binding element processing, the received IndirectSignedResponse (2.0) message is:
openid.sig: kw4f92CpwFbXgUkLs+Pf+5cFrtEzmE9KpxHgTYwi1tQ=
openid.signed: claimed_id,identity,assoc_handle,op_endpoint,return_to,response_nonce
openid.assoc_handle: he9m!IAAAAD43Voo3-zQng-ZVSKb9ryFVSIKDLJj4Ph_I9W64ypFCQQAAAAFlZWUQzOJQfO70Pvud2a--auCE7HKkFjBM45HXlpJixLEmtdgd8YPBMckvUFnIPqHBbaAk7mkhI8lDVPoKekUW
openid.invalidate_handle: 3tg1!IAAAALLyXKaShsmSDmEaKWxiBCi7-a8Nso0tyNaPKVqi52KuQQAAAAHvnjGT2Gt-_iWlSTpmBgthNS8s2Dxs6-pQG6rzYrFqgA5mp_T_HPcaJ6BchUsN9Lx2uH7jssuSAq0xbae7lb1r
openid.op_endpoint: http://www.sampleOpenIDProvider.com/OpenId/Provider
openid.return_to: http://www.samplemobilephonecompany.com/User/Authenticate?ReturnUrl=Index&dnoa.userSuppliedIdentifier=http%3A%2F%2Fwww.sampleOpenIDProvider.com
openid.response_nonce: 2012-12-03T23:59:05ZCqMBPIFL
openid.mode: id_res
openid.ns: http://specs.openid.net/auth/2.0
openid.claimed_id: http://www.sampleOpenIDProvider.com/user/justpartofthecrowd
openid.identity: http://www.sampleOpenIDProvider.com/user/justpartofthecrowd
ReturnUrl: Index   dnoa.userSuppliedIdentifier: http://www.sampleOpenIDProvider.com

Myślę, że to będzie miało znaczenie tylko dla tych, którzy wdrożyli dotnetopenauth, ale warto!

Odpowiedzi:

Przypadkowo to naprawiłem, szukającpoprzez grupy google i czytając kolejne pytanie, gdzie zawsze pomocny Andrew Arnott zasugerował sprawdzenie, czy wszystkie punkty końcowe openID są osiągalne bez autoryzacji.

Sprawdziłem więc mój kod i w instrukcji RegisterGlobalFilters znalazłem następującą instrukcję:

filters.Add(new System.Web.Mvc.AuthorizeAttribute());

Używałem tego z [AllowAhnonymous] atrybut dla wszystkich kontrolerów lub akcji, które były używane dla openID. Tak przynajmniej myślałem, ponieważ usunięcie globalnego filtru, a następnie jawne dodanie [Autoryzować] atrybut tylko do obszarów, które wymagały autoryzacji naprawił problem.