Office.context.mailbox.getCallbackTokenAsync() empty token - outlook-addin

I'm having a problem with a web add-in for Outlook.
The Outlook client is 2016 (MSI) which I believe means that it supports no higher than JavaScript API 1.4, opposed to Outlook 2016 (C2R) which, as I recall it, supports JavaScript API 1.6 or maybe even higher.
Anyway, I'm trying to use the method Office.context.mailbox.getCallbackTokenAsync(asyncResult) which has previously worked just fine on the server where it is used, but now it has stopped working for some odd reason.
The asyncResult is now empty or rather the token is empty.
{"value":"","status":"succeeded"}
How can the token be empty all of the sudden when this add-in used to work perfectly?
According to the admin of the server, it has received Windows updates on the date that this stopped working for both Office and Outlook specifically.
The Outlook clients connect to an Exchange 2013 (CU7 December 9, 2014 : 15.0.1044.25) which has also received some updates.
Both servers have been rebooted since then, but nothing has changed. The token remains empty.
Can anyone shed some light on what could be the cause of this if anyone knows that is, because all I can really do myself at this point is guess?
UPDATE 1
I have now been given permission to install Fiddler and I have found the request and respond regarding the attempt to retrieve the token.
Can any of you who know the Exchange server inside out see what is going on here, because I don't see any reasoning as to what is failing, except that the response message indicates that the request is faulty somehow (which hasn't been changed for more then a year at least).
Here is the request (some names have been replaced with something generic).
REQUEST
POST https://<domain>/ews/Exchange.asmx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
User-Agent: Microsoft Office/16.0 (Windows NT 6.3; Microsoft Outlook 16.0.4849; Pro)
X-User-Identity: <account>#<domain>.com
Depth: 0
Content-Length: 801
Host: <host>
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJ4AAABCAUIBtgAAAAAAAABYAAAANAA0AFgAAAASABIAjAAAABAAEAD4AQAAFYKI4gYDgCUAAAAPGSbYTqZVeCx7cnQxM336pnMAeQBzAHQAZQBtAGMAbwBuAG4AZQBjAHQAQABlAHMAdABpAGMAaABlAG0ALgBjAG8AbQBFAFMAVABJAC0AQwBUAFgAMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT6dTWGCCv/rRor0Srrxd9AQEAAAAAAADJcWWYQo7VATtznMo8smALAAAAAAIACABFAFMAVABJAAEAFABFAFMAVABJAC0ARQBYAEMASAAxAAQAFABFAFMAVABJAC4AbABvAGMAYQBsAAMAKgBFAFMAVABJAC0ARQBYAEMASAAxAC4ARQBTAFQASQAuAGwAbwBjAGEAbAAFABQARQBTAFQASQAuAGwAbwBjAGEAbAAHAAgAyXFlmEKO1QEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAIAAA77CK35CNnSd54Hy6NnToh6W3Oxa6tsihxlCrQ8jwDWMKABAARs+Rq8MKQZq+cmQJ8nL9/gkALABIAFQAVABQAC8AbQBhAGkAbAAuAGUAcwB0AGkAYwBoAGUAbQAuAGMAbwBtAAAAAAAAAAAAeHckPR2HOLOW0y2ri7TR1A==
Cookie: OutlookSession="{994C5944-A93C-4830-9E6F-605881790815}"; ClientId=PRHSVIWKYUDISQLQPQ
<?xml version="1.0"?>
<q:Envelope
xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:q="http://schemas.xmlsoap.org/soap/envelope/">
<q:Header>
<ex12t:RequestServerVersion Version="Exchange2012"></ex12t:RequestServerVersion>
</q:Header>
<q:Body>
<ex12m:GetClientAccessToken>
<ex12m:TokenRequests>
<ex12t:TokenRequest>
<ex12t:Id>214c1212-e3ff-45eb-9218-2deb35d6b8b9</ex12t:Id>
<ex12t:TokenType>ScopedToken</ex12t:TokenType>
<ex12t:Scope>ParentItemId:AAMkADRiMzkyMjhmLWQ1NGItNDY0Mi04Nzk0LWYyNzMzZWQ2ZGE5MABGAAAAAAApHj7qoKF1QY4+pcwfu7uCBwCHPrayw2+bT5ByF4j5Y8QZAAAAAAEMAACHPrayw2+bT5ByF4j5Y8QZAAAAAAFxAAA=</ex12t:Scope>
</ex12t:TokenRequest>
</ex12m:TokenRequests>
</ex12m:GetClientAccessToken>
</q:Body>
</q:Envelope>
RESPONSE (some names have been replaced with something generic).
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
request-id: 1a7cbf79-8ba3-4a73-bfa2-1733d841b2b1
X-CalculatedBETarget: <server>.local
X-DiagInfo: <server>
X-BEServer: <server>
X-AspNet-Version: 4.0.30319
Set-Cookie: exchangecookie=2cd797c5290345a7861dfe60e16ecc12; expires=Thu, 29-Oct-2020 10:21:15 GMT; path=/; HttpOnly
Set-Cookie: X-BackEndCookie=S-1-5-21-2060358956-2462126529-2132206371-1263=u56Lnp2ejJqBmpzHns+cypzSncaZzdLLmprH0p3HxsvSm5yaycuazMieys/MgYHNz87G0s7O0s3Hq87Pxc3Oxc7K; expires=Thu, 28-Nov-2019 09:21:15 GMT; path=/ews; secure; HttpOnly
Persistent-Auth: true
X-Powered-By: ASP.NET
X-FEServer: <server>
Date: Tue, 29 Oct 2019 10:21:15 GMT
Content-Length: 1148
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1044" MinorBuildNumber="21" Version="V2_22"
xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</s:Header>
<s:Body
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<m:GetClientAccessTokenResponse
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:GetClientAccessTokenResponseMessage ResponseClass="Error">
<m:MessageText>The token for this extension could not be retrieved.</m:MessageText>
<m:ResponseCode>ErrorInvalidClientAccessTokenRequest</m:ResponseCode>
<m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
</m:GetClientAccessTokenResponseMessage>
</m:ResponseMessages>
</m:GetClientAccessTokenResponse>
</s:Body>
</s:Envelope>

Related

Sonos Music API getDeviceAuthToken retry responses not working

We've registered our service on the customsd page, and we're able to select it from the Add Music Services menu option. However, we're running into some difficulty during authorization.
When we start the sign in process, Sonos makes a getAppLink request to our service, we respond, and the button successfully takes the user to our sign-in page. That piece appears to be working.
However, we're running into issues with the getDeviceAuthToken polling that Sonos is doing. Once the sign-in process starts, Sonos consistently sends three getDeviceAuthToken requests and then gives up, sending no more requests even though we give back the necessary retry responses.
The requests from Sonos look like this (with some information partially or fully redacted and formatting added to the body for readability):
POST <our_soap_endpoint> HTTP/1.1
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
Accept-Encoding: gzip
Accept-Language: en-US
Host: <our_site>
Max-Forwards: 10
User-Agent: Linux UPnP/1.0 Sonos/51.1-67300 (ICRU_iPhone11,8)
X-Sonos-Controller-ID: 02A4****
X-Sonos-Api-Key: 4348****
X-Sonos-Corr-Id: 0b99****
SOAPACTION: "http://www.sonos.com/Services/1.1#getDeviceAuthToken"
X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443
X-ORIGINAL-HOST: <our_site>
X-Original-URL: <our_soap_endpoint>
X-Forwarded-For: <some_ip_address>
X-ARR-SSL: 2048|256|C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA|C=US, S=Ohio, L=Cleveland, O="OverDrive, Inc.", OU=OverDrive IT, CN=*.overdrive.com
X-ARR-LOG-ID: 5188****
Content-Length: 548
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<credentials xmlns="http://www.sonos.com/Services/1.1">
<deviceId>78****</deviceId>
<deviceProvider>Sonos</deviceProvider>
</credentials>
<context xmlns="http://www.sonos.com/Services/1.1">
<timeZone>-4:00</timeZone>
</context>
</s:Header>
<s:Body>
<getDeviceAuthToken xmlns="http://www.sonos.com/Services/1.1">
<householdId>Sonos_sIGu****</householdId>
<linkCode>ab76****</linkCode>
</getDeviceAuthToken>
</s:Body>
</s:Envelope>
Our responses look like this (again with some information partially or fully redacted and formatting added to the body for readability):
HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"
Server: Microsoft-IIS/10.0
Date: Fri, 30 Aug 2019 13:25:25 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode>Client.NOT_LINKED_RETRY</faultcode>
<faultstring>No token found for link code ab76****. Please retry.</faultstring>
</s:Fault>
</s:Body>
</s:Envelope>
From what we can tell based on the documentation for getDeviceAuthToken and error handling / faults, our responses appear to match what's expected for telling Sonos to try again. Are we missing something or doing something incorrectly?
Your response does not look correct. It should be something like this:
. . .
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.sonos.com/Services/1.1">
<soap:Body>
<soap:Fault>
<faultcode>Client.NOT_LINKED_FAILURE</faultcode>
<faultstring>Access to token failed</faultstring>
<detail>
<ns:ExceptionInfo>Restart authentication.</ns:ExceptionInfo>
<ns:SonosError>6</ns:SonosError>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
See HANDLING ERRORS DURING AUTHENTICATION for details.

WSO2 AuthenticationAdmin Logout

I am working with version 4.1.0 of the WSO2 Identity Server. I have used the WSO2 AuthenticationAdmin services (localhost:9443/services/AuthenticationAdmin) to login, check authenticator, etc. There is also an operation for 'logout'.
When soapUI generates the logout request, it does not contain any noteworthy elements, as is confirmed by the schema (xsd) with the namespace http://authentication.services.core.carbon.wso2.org. The SOAP request body is as follows.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:aut="http://authentication.services.core.carbon.wso2.org">
<soap:Header/>
<soap:Body>
<aut:logout/>
</soap:Body>
</soap:Envelope>
When sending a request, the RAW response is as follows.
HTTP/1.1 202 Accepted
Date: Wed, 26 Jun 2013 08:29:48 GMT
Server: WSO2 Carbon Server
Content-Type: text/xml;charset=UTF-8
Set-Cookie: JSESSIONID=94784CC9FC03E9FA3822CFDDAD0D36F6; Path=/; Secure; HttpOnly
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
First of all, do I think there is no SOAP message in the response. Also, the HTTP status is 202, which means that the request is accepted for processing, but the processing has not yet been completed.
How do I logout with this service?
What elements should be added to the < aut:logout > ?
Should a JSESSIONID be added to the header of the request?
How can this logout be combined with the loginWithRememberMeOption ?
------- UPDATE
After reviewing the xsd I saw that a wsa:action must be added to the SOAP Header. After doing this, I received the following reply. This reply asks for a MessageID. But I am not sure what this value should be.
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://www.w3.org/2005/08/addressing/fault</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Sender</soapenv:Value>
<soapenv:Subcode>
<soapenv:Value xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageAddressingHeaderRequired</soapenv:Value>
</soapenv:Subcode>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">A required header representing a Message Addressing Property is not present</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail>
<wsa:ProblemHeaderQName xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageID</wsa:ProblemHeaderQName>
</soapenv:Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
When adding a generated MessageID, the is once again an empty SOAP reply with a HTTP 202 status.
The logout method just invalidates the session.
You just call the logout operation as it is from the soapUI. There are no parameters to it.
If you look at the AuthenticationAdmin WSDL, you can see that there is no output for logout operation. That's why you get HTTP 202 status code.
You can view the WSDL by changing <HideAdminServiceWSDLs> configuration to false in carbon.xml (/repository/conf/carbon.xml)
<HideAdminServiceWSDLs>false</HideAdminServiceWSDLs>
Type following in your browser to view the WSDL.
https://:9443/services/AuthenticationAdmin?wsdl
I hope this helps!

WSO2IS: SAML request encoding / decoding

I am using WSO2 Identity Server 4.1.0. I have successfully followed the steps described here (thank you) to get a local SAML2 consumer to work with a local WSO2 Identity Server.
The steps mentioned above describe using a Tomcat webapp to 'call' the login page of the WSO2 Identity server, using a SAML request. The webapp will also receive a SAML response. The webapp has to generate this SAML request, so that it contains a valid issuer, timestamp, etc. Without this request, the Identity Server will not provide a login page. So actually, the request is a sort of preperation. The SAML request is encoded.
My aim is to get a better understand of the way in which this webapp is composing the initial SAML request. I was only able to see the request, after using SAML debugger. How can I view this SAML request manually, using decoders?
What I have learned so far:
I have learned here that we can use SAML 2.0 Debugger to decode or encode the saml requests and responses. But I would like to how and what is getting encoded / decoded.
I have learned here that a URL decoder and Base64 decode might be needed. So I was able to URL decode the /samlsso?SAMLRequest. It contained an encoded assertionString. I was not able to Base64 decode this string.
Request HTTP Header:
This request is send to the WSO2 Identity Server.
https://localhost:9443/samlsso
POST /samlsso HTTP/1.1
Host: localhost:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://localhost:9443/samlsso?SAMLRequest=jZPBbtswDIZfRdA9seO0WyzEKbIUxQx0m5u4O%2BymyswiQJY8kU6zt5%2Fs2GsORdCrSP7k%2F5Fa3p1qw47gUTub8dk05gyscpW2vzP%2BXD5MFvxutURZm0asWzrYLfxpAYmFOouiD2S89VY4iRqFlTWgICV262%2BPIpnGovGOnHKGszUieAqNNs5iW4PfgT9qBc%2Fbx4wfiBoRRcYpaQ4OSSziRRx1%2Bsm0gtpFaigKOkRev7QEZ50w6iCU2wpOwUUyT5Ob2%2FQm5ezBeQX94BnfS4PAWX6f8WAzx0Ii6iO8BRDboIEkLWU8iWfzSfx5EidlnIp5Ima300%2Bz9BdnxeDoi7ZnTtfsv5yTUHwty2JS%2FNiVnP0ceYcEPtLtu%2FuPc5UjTb56o7SMLsVG6e%2BhOL8vnNHqL1sb4143HiQF5%2BRb6CHVkq636150Ndn3qaLpHCCBJc52Raf%2F1Eqj9xp8xvNuMh6N3YeLgapfQ9gZwYnYxtWN9Bo7DHCSigYQ4jJrY4LLLewvqHwYytU0JVQnHZ67I3h1vuqWCipMWXppsXGezizfnWc1cn7X2%2F%2Fo5YdZ%2FQM%3D&RelayState=null
Cookie: MSG13721655096400.5456646701125957=true; MSG13721655827030.13073174051588388=true; MSG13721677790000.949325276640498=true; menuPanel=visible; menuPanelType=main; current-breadcrumb=manage_menu%2Cmanage_saml_sso%23; requestedURI=../../carbon/admin/index.jsp; Modernizr=; JSESSIONID=E4B3DB007762167497588E63D2C396F6; MSG13727573306230.10612530425878663=true; region1_manage_menu=visible; ssoTokenId=E4B3DB007762167497588E63D2C396F6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 806
username=admin&assertnConsumerURL=http%3A%2F%2Flocalhost%3A8080%2Fsaml2.demo%2Fconsumer&issuer=saml2.demo&id=0&subject=null&relyingPartySessionId=null&assertionString=jZPBbtswDIZfRdA9seO0WyzEKbIUxQx0m5u4O%2BymyswiQJY8kU6zt5%2Fs2GsORdCrSP7k%2F5Fa3p1qw47gUTub8dk05gyscpW2vzP%2BXD5MFvxutURZm0asWzrYLfxpAYmFOouiD2S89VY4iRqFlTWgICV262%2BPIpnGovGOnHKGszUieAqNNs5iW4PfgT9qBc%2Fbx4wfiBoRRcYpaQ4OSSziRRx1%2Bsm0gtpFaigKOkRev7QEZ50w6iCU2wpOwUUyT5Ob2%2FQm5ezBeQX94BnfS4PAWX6f8WAzx0Ii6iO8BRDboIEkLWU8iWfzSfx5EidlnIp5Ima300%2Bz9BdnxeDoi7ZnTtfsv5yTUHwty2JS%2FNiVnP0ceYcEPtLtu%2FuPc5UjTb56o7SMLsVG6e%2BhOL8vnNHqL1sb4143HiQF5%2BRb6CHVkq636150Ndn3qaLpHCCBJc52Raf%2F1Eqj9xp8xvNuMh6N3YeLgapfQ9gZwYnYxtWN9Bo7DHCSigYQ4jJrY4LLLewvqHwYytU0JVQnHZ67I3h1vuqWCipMWXppsXGezizfnWc1cn7X2%2F%2Fo5YdZ%2FQM%3D&RelayState=null&password=admin
HTTP/1.1 200 OK
Set-Cookie: ssoTokenId=E4B3DB007762167497588E63D2C396F6; Expires=Tue, 02-Jul-2013 19:32:45 GMT
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Tue, 02 Jul 2013 09:32:45 GMT
Server: WSO2 Carbon Server
The 'referer' in the request above contains a SAML request, that was made visible by the SAML Debugger.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://localhost:8080/saml2.demo/consumer" AttributeConsumingServiceIndex="1239245949" ForceAuthn="false" ID="0" IsPassive="false" IssueInstant="2013-07-02T09:32:15.619Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">saml2.demo</samlp:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="Isser"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
(It seems it is not the full SAML request yet, and that the WSO2 IS is composing the complete SAML Request internally.)
Response HTTP Header:
This is the response received from the WSO2 Identity Server.
http://localhost:8080/saml2.demo/consumer
POST /saml2.demo/consumer HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=E078F376C8ED303D28A200DD7AC28324; MSG13721655096400.5456646701125957=true; MSG13721655827030.13073174051588388=true; MSG13721677790000.949325276640498=true; menuPanel=visible; menuPanelType=main; current-breadcrumb=manage_menu%2Cmanage_saml_sso%23; requestedURI=../../carbon/admin/index.jsp; Modernizr=; MSG13727573306230.10612530425878663=true; region1_manage_menu=visible; ssoTokenId=E4B3DB007762167497588E63D2C396F6
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 1870
SAMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3Csaml2p%3AResponse+ID%3D%22dnfomflkhhdjjgfoggoagcdopgnjmpajenlehbka%22+IssueInstant%3D%222013-07-02T09%3A32%3A45.635Z%22+Version%3D%222.0%22+xmlns%3Asaml2p%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aprotocol%22%3E%3Csaml2p%3AStatus%3E%3Csaml2p%3AStatusCode+Value%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Astatus%3ASuccess%22%2F%3E%3C%2Fsaml2p%3AStatus%3E%3Csaml2%3AAssertion+ID%3D%22dgamkdkadflnniggkelmjfakjljedhfdhnbpomdk%22+IssueInstant%3D%222013-07-02T09%3A32%3A45.635Z%22+Version%3D%222.0%22+xmlns%3Asaml2%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%3Csaml2%3AIssuer+Format%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Anameid-format%3Aentity%22%3Ehttps%3A%2F%2Flocalhost%3A9443%2Fsamlsso%3C%2Fsaml2%3AIssuer%3E%3Csaml2%3ASubject%3E%3Csaml2%3ANameID%3Eadmin%3C%2Fsaml2%3ANameID%3E%3Csaml2%3ASubjectConfirmation+Method%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Acm%3Abearer%22%3E%3Csaml2%3ASubjectConfirmationData+InResponseTo%3D%220%22+NotOnOrAfter%3D%222013-07-02T09%3A37%3A45.635Z%22+Recipient%3D%22http%3A%2F%2Flocalhost%3A8080%2Fsaml2.demo%2Fconsumer%22%2F%3E%3C%2Fsaml2%3ASubjectConfirmation%3E%3C%2Fsaml2%3ASubject%3E%3Csaml2%3AConditions+NotBefore%3D%222013-07-02T09%3A32%3A45.635Z%22+NotOnOrAfter%3D%222013-07-02T09%3A37%3A45.635Z%22%3E%3Csaml2%3AAudienceRestriction%3E%3Csaml2%3AAudience%3Esaml2.demo%3C%2Fsaml2%3AAudience%3E%3C%2Fsaml2%3AAudienceRestriction%3E%3C%2Fsaml2%3AConditions%3E%3Csaml2%3AAuthnStatement+AuthnInstant%3D%222013-07-02T09%3A32%3A45.635Z%22%3E%3Csaml2%3AAuthnContext%3E%3Csaml2%3AAuthnContextClassRef%3Eurn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aac%3Aclasses%3APassword%3C%2Fsaml2%3AAuthnContextClassRef%3E%3C%2Fsaml2%3AAuthnContext%3E%3C%2Fsaml2%3AAuthnStatement%3E%3C%2Fsaml2%3AAssertion%3E%3C%2Fsaml2p%3AResponse%3E&RelayState=null
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/saml2.demo/home.jsp?subject=admin
Content-Length: 0
Date: Tue, 02 Jul 2013 09:32:47 GMT
Here the SAMLResponse can be made visible by using a URL Decoder, for example this one.
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response ID="dnfomflkhhdjjgfoggoagcdopgnjmpajenlehbka" IssueInstant="2013-07-02T09:32:45.635Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion ID="dgamkdkadflnniggkelmjfakjljedhfdhnbpomdk" IssueInstant="2013-07-02T09:32:45.635Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://localhost:9443/samlsso</saml2:Issuer>
<saml2:Subject>
<saml2:NameID>admin</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="0" NotOnOrAfter="2013-07-02T09:37:45.635Z" Recipient="http://localhost:8080/saml2.demo/consumer"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2013-07-02T09:32:45.635Z" NotOnOrAfter="2013-07-02T09:37:45.635Z">
<saml2:AudienceRestriction>
<saml2:Audience>saml2.demo</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2013-07-02T09:32:45.635Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>
Even if this thread is old, I run into a similar Issue with the newer 5.1.0 Identity Server.
The SAMLRequest Url Parameter is decodable by first URL decode it and then Base64 inflate it e. g. on https://www.samltool.com/decode.php
There are other parameters in the Url, normally separated by "&" which must be excluded to get a successful decoding. In your example especially the "&relayState=null" at the end has to be excluded for decoding.
A redirect Binding would additionally have the deflated signature and the used digest algorithm as parameter.
This is the decoded and inflated result of the SAMLRequest param taken from question Code Snippet 1, it should cover the result from your SAML Debugger.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://localhost:8080/saml2.demo/consumer"
AttributeConsumingServiceIndex="1239245949" ForceAuthn="false" ID="0"
IsPassive="false" IssueInstant="2013-07-02T09:32:15.619Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">saml2.demo</samlp:Issuer>
<samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="Isser" />
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Refused to get unsafe header "Content-Range"

For some reason I cannot access the response header of "Content-Range" anymore... Therefore it's impossible to determine the file size of a resource using XHR.
I get error Refused to get unsafe header "Content-Range" on Chrome in this line:
var cr = this.getResponseHeader('Content-Range');
Here's the CORS config:
<?xml version="1.0" ?>
<CorsConfig>
<Cors>
<Origins>
<Origin>*</Origin>
</Origins>
<Methods>
<Method>GET</Method>
<Method>HEAD</Method>
<Method>DELETE</Method>
</Methods>
<ResponseHeaders>
<ResponseHeader>x-goog-meta-foo1</ResponseHeader>
<ResponseHeader>origin</ResponseHeader>
<ResponseHeader>range</ResponseHeader>
<ResponseHeader>Content-Range</ResponseHeader>
<ResponseHeader>Content-Length</ResponseHeader>
</ResponseHeaders>
<MaxAgeSec>1800</MaxAgeSec>
</Cors>
CURL output:
$ curl -H "Origin: http://peer5.com" http://commondatastorage.googleapis.com/peer5_vod/wind2_orig.mp4 -s -D - -o /dev/null
HTTP/1.1 200 OK
Server: HTTP Upload Server Built on May 8 2013 16:51:19 (1368057079)
Expires: Mon, 13 May 2013 09:47:40 GMT
Date: Mon, 13 May 2013 08:47:40 GMT
Cache-Control: public, max-age=3600, no-transform
Last-Modified: Fri, 22 Mar 2013 17:09:47 GMT
ETag: "755232ae8fef22bc7b4e9510a68a646e"
x-goog-generation: 1363972188238000
x-goog-metageneration: 2
Content-Type: video/mp4
x-goog-hash: crc32c=pZmS2Q==
x-goog-hash: md5=dVIyro/vIrx7TpUQpopkbg==
Accept-Ranges: bytes
Content-Length: 15535795
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Length, Date, Server, Transfer-Encoding
This appears to be a bug on our side. Only the last header value in the ResponseHeaders list is returned in the Access-Control-Expose-Headers header. We are working on rolling out a fix, but as a workaround, if you only need the Content-Range header (Content-Length is considered a simple header by the CORS spec and is added automatically), please try setting your CORS config to this:
<?xml version="1.0" ?>
<CorsConfig>
<Cors>
<Origins>
<Origin>*</Origin>
</Origins>
<Methods>
<Method>GET</Method>
<Method>HEAD</Method>
<Method>DELETE</Method>
</Methods>
<ResponseHeaders>
<ResponseHeader>Content-Range</ResponseHeader>
</ResponseHeaders>
<MaxAgeSec>1800</MaxAgeSec>
</Cors>
</CorsConfig>
UPDATE: This bug has been fixed.

Cliqset.com Error 403 while trying to update any data through API

I used both Fiddler and my test C# application to update my profile information in Cliqset.com through their API but I always get 403 error. It works well when I just want to get my profile info, not to update. I use all necessary HTTP headers, like CliqsetConsumerKey and Authorization.
Thank you.
When I try to get my status, I use this:
GET https://api.cliqset.com/user/cosmorocket/status HTTP/1.1
Authorization: Basic Y**********rZXQ6ZnVsY3J1bTA=
CliqsetConsumerKey: 11**********3c2ccd26c4ca946e3d8e
Host: api.cliqset.com
And it returns this:
HTTP/1.1 200 OK
Date: Fri, 10 Jul 2009 05:17:37 GMT
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0
Content-Type: application/xml
Content-Length: 153
Set-Cookie: csp=appInst2; path=/
Connection: close
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><StatusEntry><Updated>2009-06-09T18:09:29.315Z</Updated><Status>cliqsetting all day long</Status></StatusEntry>
But if I use the same credentials for updating with this request:
PUT https://api.cliqset.com/200905/user/cosmorocket/status HTTP/1.1
I get this:
HTTP/1.1 403 Forbidden
Date: Fri, 10 Jul 2009 05:25:04 GMT
Vary: Accept-Encoding
Content-Length: 9
Connection: close
Content-Type: text/html; charset=iso-8859-1
Error 403
I contacted tech support and solved the problem. Each time a new user uses my registered application it's necessary to make an authenticated GET
request to 'https://api.cliqset.com/200905/user/useridentifier'. Notice that you don't change 'useridentifier' to any other login name, just leave it as it is. This
will setup the appropriate permissions to update data.
I did this request and now it works well.