I am creating a clone of the facebook Rest API in c#, I am testing it with the facebook PHP sdk. The problem I am having is that the responses sent by my net Rest Service contain utf-8 Bom in front of it and Facebook SDK is not able to parse the responses correctly.
Any ideas on how to resolve this problem.
If you can specify a specific Encoding to your service, then you can use new UTF8Encoding(false) which is UTF-8 without BOM.
I don't know what you are returning in your service, but if it is a string like mine (I was returning a json), you can simply return a Message object instead with the string in it (from System.ServiceModel.Channels - google it) and then at the end of your service method implementation just do this:
Encoding utf8 = new System.Text.UTF8Encoding(false); //false == no BOM
return WebOperationContext.Current.CreateTextResponse(stringWithContent, "application/json;charset=utf-8", utf8);
The Wikipedia UTF-8 article suggests that the pretend-BOM that Windows applications frequently prepend to the actual content is three bytes long. Can you simply not send the first three bytes of your generated content?
Related
I am fetching my organization's applications using the MS Graph API, and I am attempting to read the thumbprints of the certificates attached to each. It returns a byte[] but I can't seem to find the right encoding to convert to string.
The graph API returns a list of Application objects, which have a KeyCredentials enumerable, and finally a CustomKeyIdentifier, which should be the thumbprint. See this Microsoft page for more details on KeyCredentials.
The code I have tried is
System.Text.Encoding.ASCII.GetString(credential.CustomKeyIdentifier);
This returns gibberish characters, presumably because the encoding is incorrect, but I have tried every other encoding option available in Text.Encoding to no avail. How can I convert the CustomKeyIdentifier to a string?
It should be a Base64 string so
System.Convert.ToBase64String(credential.CustomKeyIdentifier);
Or if you want the Hex version which is generally what people want when looking at the thumbprint it would be
BitConverter.ToString(credential.CustomKeyIdentifier).Replace("-","");
I'm setting up a service to be a SAML2.0 Service Provider (SP). As such, I need to generate SAML Requests and I need to accept SAML Responses. SAML Responses (with IDP initiated assertions) may come without request. This is just the world of SSO and SAML, and I have this much working.
My sense is that SAML Requests or Responses may or may not be deflated. It seems to be good practice for a SP to deflate SAML Requests.
Requests and Responses are also Base 64 Encoded. But here lies my question. Let us say that I get a SAML Response. It is Base 64 Encoded. When I decode that, I get a byte array. Assuming that this is NOT deflated, I now need to get a string out of that byte array in order to treat it as XML.
What encoding should I assume for that string?
So, in the c#/.NET/MVC world:
public ActionResult ConsumeSamlAssertion(string samlResponse)
{
if (string.IsNullOrWhiteSpace(samlResponse))
{
return Content("Consumption URL hit without a SAML Response");
}
// MVC Already gives me this URL-decoded
byte[] bytes = Convert.FromBase64String(samlResponse);
// For this question, assume that this is not deflated.
string samlXmlIfAscii = Encoding.ASCII.GetString(bytes);
string samlXmlIfUtf8 = Encoding.UTF8.GetString(bytes);
// Which is correct? Or is there a different one?
Is this in some standard I have missed (which isn't for want of looking)?
Many thanks.
I can't find anything authoritative in the SAML2 specification on what encoding to use. I've used UTF8 and it works.
Regarding the deflate step - that depends on the binding. In the redirect binding where the message is passed in the query string, it is deflated. In the POST binding where it is past as a form field it is not deflated.
Also I'd suggest that you look at existing SAML2 stacks for .NET instead of rolling your own. It's a lot of work doing SAML2 right, and it's easy to get security issues such as XML signature wrapping.
SAML requests and responses are in XML format, so this boils down to the question how to encode XML data.
See for example: Meaning of - <?xml version="1.0" encoding="utf-8"?>
The default encoding for XML (if no preamble is present, or it does not specify an encoding) is UTF-8. Therefore, we can say that the XML specification authoritatively specifies that UTF-8 CAN be used.
Whether all SAML implementations, and the SAML specification itself, allow other encodings is unclear to me, but using UTF-8 should be safe.
I m making calls to a third party API over HTTP and passing a string in the parameters. This string is UTF-8 URL encoded. My API client is written in asp.net C# where as the API host is probably written in Java. When I have characters like parenthesis/brackets () in the string parameter, UTF-8 encoder does not encode them whereas the API host encodes them in %28 and %29 and I get incorrect response. Any suggestions how to fix this encoding problem?
(API documentation specify to use UTF-8 encoding and recommends to refer this document http://docs.oracle.com/javase/6/docs/api/java/net/URLEncoder.html)
There are some little known Uri methods:MSDN
Uri.EscapeString and Uri.EscapeDataString may fit the bill. unfortunately there is no MSDN documentation on what characters they will encode , you will just have to experiment.
I'm writing a .Net 3.5 solution which is consuming a 3rd party WCF web service. The proxy client for the SOAP service was generated by VisualStudio as a service reference.
A SOAP response from the service includes attachments in the data, as I can see it in fiddler. The attachments have a href field which points to a CID reference. The proxy client that VS 2012 has created when returning the object which includes the attachments doesn't include any binary data, but it does include the href field with the CID reference in it.
As captured using fiddler, this is the SOAP response attachment data including the cid:xxxx ref:
<attachments>
<cmn:attachment href="cid:52b2d8a50035921e80bf1540" len="309" name="DOC1.rtf" type="application/rtf" xmime:contentType="application/rtf"/>
</attachments>
And in the raw output in fiddler, the attachment data can be seen with the matching cid:xxxx ref:
------=_Part_22_12445037.1389617382038
Content-Type: application/rtf
Content-Location: DOC1.rtf
Content-ID: <52b2d8a50035921e80bf1540>
Content-Transfer-Encoding: binary
{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\fnil\fcharset0 Calibri;}}
{\*\generator Msftedit 5.41.21.2510;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\f0\fs22 Doc 1\par
\par
Test information inside an attachment for KM retrieval.\par
\par
Here's something else I've written for use in testing.\par
}
Here is a screenshot of the available fields from the returned object:
How do I access that attachment data so I can actually download the file?
Normally with WCF and SOAP, your file binary is encoded as a base64 string somewhere in your response, however I don't see in what you've posted here the kind of long data string I'd be expecting.
If what you're showing here is just the header from the response, you might check the body of the response message,too, since the header has a size limit, but the body the message doesn't - it's therefore the likely place for your binary payload.
Wouldn't it be easier to return a byte[] in one of the entities you are returning, and then work from that on your client to reconstruct the file?
Are you using MTOM? Because WCF does not support SwA (Soap with attachments) out of the box.
Turns out that the issue was due to the way the 3rd party API was returning the response, the MTOM data was not correctly formatted so WCF was ignoring the binary data.
The way I got around this was by using a bespoke class which basically uses an HttpRequest to talk directly to the web service and extract/parse the binary data out of the response.
I have an .net 2.0 C# client app that has a web service reference to an Axis2 Java Webservice.
The idea is to send some xml data to the webservice, so it can be parsed and inserted into database.
The WS method accepts a single parameter of type 'xsd:anytype'.
Java web service:
public class JWS{
public Response AddData(Object inputXML) {
return Response;
}
}
C# Client:
JWS client = new JWS();
object inputXML = "<xml>some xml data</xml>";
response = client.AddData(inputXML);
There are 2 issues i am seeing when monitored using fiddler.
1) The request has an additional element '<inputXML>' added before the actual xml data.
<inputXML><xml>some xml data</xml></inputXML>
2) The xml is encoded, so '<' is appearing as "<"
I am not sure if this is how SOAP request's are generated but i would like to remove the <inputXML> tag and also, have the xml appear as is without having to replace the special characters.
Is this possible? Is it got something to do with 'Wrapping'/'UnWrapping' Types?
Also, i have used SoapUI to test the java web service and it works well. However, in the request tab, i had to manually remove the <inputXML> tag and submit for it to work correctly. Please help.
TIA
This is expected behaviour under SOAP and the inputXml variable will be decoded back to the original string when passed to your web service method.
However this may indicate a problem with your design, have you considered constructing an object to send to your web service rather than xml data? (As this object will transparently be converted to xml for the web service call anyway).
I found out that the issue is not with encoding but it was interpreted incorrectly on java side when the message was viewed in axis2. So, it is getting decoded properly. Also, the inputxml is now being handled correctly.