I'm sending an OAuth callout to https://start.exactonline.nl/api/oauth2/token
When the Refresh Token is expired Exact Online returns an invalid messages. The response that is returned contains 2 WWW-Authentication headers (where 1 is blank).
Java request handling does not accept this and throws an exception;
Since Salesforce doesn't handle low-level Java exceptions it is impossible to handle authentication responses with empty WWW-Authentication headers.
A discussion around this issue handling empty WWW-Authentication headers:
http://cxf.547215.n5.nabble.com/jira-Created-CXF-4318-OAuthRequestFilter-generates-an-empty-WWW-Authenticate-header-td5707908.html
What I would like to know is:
Get in touch with someone from the EOL API team to fix this bug
Is there anyone who knows how to handle a Java exception in Apex
Related
Here is an image of a common structure we have in a few of our BizTalk orchestrations:
So when we GET information from an API and the account doesn't exist, we terminate the orchestration. This works fine and I can see the orchestration doing this and terminating when it should, but what I don't understand is why do I see the suspended message from the GET in the console? Since the exception handling works, shouldn't this stop an error showing in the console?
As a way around this, I've considered using a pipeline component to check the response message, and if it contains what would be ignored, just return null in place of the message. Would this have the desired effect? I'm more interested as to why I see the suspended messages in the console.
Yes, this is a known issue with the WCF-WebHttp adapter, that has to do with the fact that it throws it back as a SOAP formatted error, but without setting the MessageType context property (see my blog post and look for Bug: BizTalk WCF-WebHttp adapter does not set the message type on error). So although the exception is thrown back at the Orchestration and can be handled there, the message is not as BizTalk does not know what type it is and it suspends.
A workaround we use is
To set Enable Routing for failed messages on the send port
To have a send port that subscribes to all the response messages from that send port using the BTS.SPName = xxxx filter, and send port sends it to a custom NULL adapter (throw the message away), and yes, your Orchestration will still get the good response as well as the exceptions.
Update the send port that handles routing errors from other send ports that we do want to go to our exception handing to exclude those send ports which we are handling via an Orchestration.
I am implementing an RESTful Webservice which returns every content formatted as JSON. I am also using Spring OAuth2, but all error messages like invalid access token etc are returned in XML format. How can I return these OAuth2 errors as JSON?
By the way, the access tokens are returned as JSON String.
We have faced the same problem.
After hours and hours of configuring it on server side we have found better way to migrate this nuisance.
Error messages for OAuth2 for Spring defaults to xml but with one simple trick you can change them to JSON: by sending Accept: application/json in request headers.
Hope I helped a bit.
I am using the native Facebook SDK (through an opensource tool called 'SimpleFacebook') to authenticate with Facebook. That part is working great. I find the Microsoft Azure implementation of Facebook authentication to be lacking.
Anyway, the next step is to use the token from this Facebook session and authenticate with MS/Azure. There are two methods like look like they should do the job
public void login(java.lang.String provider,
java.lang.String oAuthToken,
UserAuthenticationCallback callback)
Invokes Windows Azure Mobile Service authentication using a provider-specific oAuth token
Parameters:
provider - The provider used for the authentication process
oAuthToken - The oAuth token used for authentication
callback - Callback to invoke when the authentication process finishes
And another very similar method where the second param is a JSON object of type:
com.google.gson.JsonObject oAuthToken,
Is it just me or is the documentation lacking here? I tried just calling the Facebook session's .getAccessToken() and passing that to the functions and I get an error from Azure:
Caused by: com.microsoft.windowsazure.mobileservices.MobileServiceException: {"code":400,"error":"Error: invalid json"}
at com.microsoft.windowsazure.mobileservices.MobileServiceConnection$1.onNext(MobileServiceConnection.java:115)
How do we know what the correct JSON format is?
Am Using the right token?
More information can be found at:
at this Azure site
I think I have this figured out. Essentially all I had to do was create a JSON object (which is fairly new for me). I tried this earlier but I had imported the wrong JSON class (I had imported org.json.JsonObject or something rather than the com.google.gson.JsonObject).
once I did that I had to figure out what the correct json properties should be. Through a lot of Google searches I found out this is the correct format:
JsonObject jo = new JsonObject();
jo.addProperty("access_token", token);
Then use jo.toString() in the call like:
mClient.login(MobileServiceAuthenticationProvider.Facebook, jo.toString(), new UserAuthenticationCallback() {
.....
}
Really not that difficult, but why wouldn't Azure team put this in their docs???
Maybe this is just "obvious" information for a seasoned dev, but it took me a whole evening to figure out.
I've implemented logging of all requests/responses using (in my AppHost.cs):
this.RequestFilters.Add(serviceLogFilter.LogRequest);
this.ResponseFilters.Add(serviceLogFilter.LogResponse);
During the logging of the request, I get the new ID from the logging table and put it into IHttpRequest.Items.
My question is: when an error occurs, like if the validation of the incoming data fails, or my business logic throws an Exception, is there a way I can customize the returned error to contain my log reference? Preferably by adding a JSON body to the error response. Alternatively, setting a custom HTTP header?
The idea is that my customer could give me a log reference if something unexcpected happens, and I would find his request and could easily reproduce the problem.
See this question on different ways to Handle exceptions from the old and New API.
To use the IHttpRequest.Items dictionary to pass data between request filters, services and response filters in the same request.
Also the InMemoryRollingRequestLogger implementation for the Request Logger plugin shows another way to be able to log all requests.
We are in the middle of a ongoing discussion about how to handle REST exceptions.
Response Content type : JSON
Two solutions we have:
Throw all the unchecked exceptions as a JSON response.
Send Request Invalid Response code.
Arguments:
When its a error, why return JSON? Just send a invalid response code.
Counter Argument:
Response code are too technical to handle for normal developers.
Whats your say??
For a JSON API I recently developed I do both. I always respond with valid JSON (well, assuming I respond at all). If I detect an invalid request, I use status 400. If I detect a server error (which I don't believe is caused by an invalid request), I use a 5xx status. The JSON object contains a special key that is only set for errors, with a string value.
I think this is a good solution that respects REST principles, and can be used in multiple ways. The same solution is used by some other JSON APIs, such as Yahoo Search. Try http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json .
Use error codes like for HTTP. So 50* for any exception cause by some internal problem. And 40* for bad arguments. Avoid using your own defined codes as far as its possible. The idea is to have a "uniform" interface.
In general.
204 for success without sending any content
200 for success with a json representation of the resource
And if its not a successful operation return appropriate response code. You can choose to optionally return a json. To simplify things you can have a common format (json) for all error responses.
http://en.wikipedia.org/wiki/REST is a must read before you freeze on your api specs.