5

Ich habe ein Problem beim Versuch, eine Webrequest zu UGC und authentifizieren mit oAuth. Ich mache eine webrequest wie: -Tridion UGC-Dienst und oAuth-Authentifizierung

WebRequest wr = WebRequest.Create("http://ugc.service/odata.svc/Ratings(Id=200)"); 
wr.Headers["authorization"] = "OAuth " + auth; 

Wo Auth mein Token aus dem access_token.svc zurückgeführt wird.

HufXeuUt% 2FYYElA8SYjJOkUkrXxV9dyXRirmKhjW% 2Fb% 2FU% 3D

Doch was aus access_token.svc zurück ich bin eher wie -:: Nach der Dokumentation der Token aus dem Dienst zurück sollen so etwas wie -

{ "access_token": "client_id% 3dtestuser% 26expiresOn% 3d1361898714646% 26digest% 3d% 2FW% 2fvyhQneZHrm1aGhwOlgLtA9xGWd77hkxWbjmindtM% 3d", "expires_in": 300}

ich die JSON analysiert habe verschiedene Zeichenfolgen zu extrahieren und Ich habe versucht, diese an die Autorisierung zu übergeben, aber was auch immer ich versuche, ich bekomme einen Fehler in der lo gs - "Fehler OAuth2AccessToken - Digest ist falsch." Welchen Teil des Tokens und in welchem ​​Format soll ich zur Autorisierung weitergeben?

Vielen Dank

John

+0

Schwierige Frage, ich habe kaum Erfahrung mit OAuth. Aber ich weiß, dass den Eigenschaften, die durch die Header übergeben werden, das Präfix oauth_ z. oauth_consumer_key, oauth_token. Die zurückgegebenen Eigenschaften scheinen mir in einer Abfragezeichenfolge verwendbar zu sein. Die Verwendung einer OAuth-Bibliothek könnte Ihnen ein wenig helfen. http://oauth.net/code/ –

+1

Ich habe retagged, um oauth und odata einzuschließen, da dies eher ein Problem als Tridion scheint. Versuchen Sie auch, nach Fragen zu diesen Themen zu suchen. –

Antwort

5

Wie Sie erwähnt haben, ist das Protokoll, das:

  1. Sie ein Post Anforderungs-Token Endpunktes zum Zugriff machen einen Token zu bekommen (man braucht um hier Ihre client_id und Ihre client_secret als Header oder als Abfrageparameter anzugeben);

  2. Sie erhalten eine Antwort ähnlich der folgenden: {"access_token":"sometoken","expires_in":300}; 2.1 Gut zu wissen ist, dass das Token URL-codiert und im UTF-8-Format ist, also auf Java-Seite müssen Sie URLDecoder.decode("sometoken", "UTF-8"); tun, während auf .NET-Seite müssen Sie tun HttpUtility.UrlDecode("sometoken", System.Text.Encoding.UTF8);;

  3. Ihre nächste Anfrage muss den Berechtigungsheader enthalten. Auf Java-Seite tun Sie builder.header("authorization", "OAuth " + decodedTokenString); während auf .NET Seite Sie Client.Headers["authorization"] = "OAuth " + DecodedTokenString;

Erwähnenswert ist, dass die Sharedsecret definiert im cd_webservice_conf.xml (/Configuration/AuthenticationServer/SharedSecret/) des TokenAccessPoint die gleiche sein muss wie die Sharedsecret definiert können in die cd_ambient_conf.xml (/Configuration/Security/SharedSecret/) des (WebService) EndPoint.

Sind Sie sicher, dass Sie das vom Server erhaltene Token korrekt decodiert haben? Sind Sie sicher, dass Sie den richtigen SharedSecret in den beiden Konfigurationsdateien konfiguriert haben?

Hoffe, das hilft.

+0

Hallo Daniel, tut mir leid, dass ich nicht früher aktualisiert habe. Es war die Decodierung des Tokens, wie Sie richtig angemerkt haben, und ein falscher Konfigurationswert, der uns das Problem verursacht hat. Alles gut jetzt. Danke, John – John

Verwandte Themen