What are possible causes of ErrorMessage: Dynamic Backend Host Not Specified? - java

There is not much on SO about what to do when you are seeing <ErrorMessage>Dynamic backend host not specified</ErrorMessage> except for this question.
Hoping this will become a resource for other developers who face this issue, as well as answer my specific case.
I am trying to test that SOAP requests sent from my client (built from WSDL) can hit a server (generated from the same WSDL), the source code for which I have no access to or responsibility for.
Currently I am just curl-ing against the server's endpoint with my (client) certificates and some XML to POST:
curl -X POST https://www.endpoint.com/service.svc:443 --cert certificates.p12:password --cert-type pkcs12 -d ‘<example>Place Holder XML </example>’
(Can't include the actual curl request due to its confidential nature)
The server is responding with:
<?xml version="1.0" encoding="UTF-8"?>
<ErrorMessage>Dynamic backend host not specified</ErrorMessage>
The other SO answer linked above suggests that this may be a result of not including the correct headers in my request. If this is the problem in my case, does anyone know why the lack of headers is the cause of trouble here? Are there other possible causes of this error that are the responsibility of the client? Could this be an error on the server?

Related

WCF MTOM/XOP Client Deserialization Error

This is one of those SO 'questions' that i've already answered, but am posting b/c there seems to be next to zero information out there based on a week of Googling.
TL;DR: WCF MTOM encoded BasicHttpBinding client to external/3rd part, non-.NET web service chokes on XOP processing of MTOM response - basically MTOM encoder seems to be expecting a base64 payload in binary element, but runs in to the ... directive and fails deserializing SOAP/XML to runtime object, thus throwing error in this question's Title.
Error: End element 'MyBinaryData' from namespace 'http://mynamespace' expected. Found element 'xop:Include' from namespace 'http://www.w3.org/2004/08/xop/'
As previously noted, there's not much out there on this topic, i'm guessing b/c MS wrote most of their WCF documentation based on service development, and not so much client (although there is some, to be fair).
I'm not going to go in to the nitty-gritty initial set up b/c i'm about to answer my own question, but i'll preface the answer by saying that this was much more akin to a default configuration of WCF MTOM than not.
Also, i know WCF is old, boring, and no longer actively developed by MS, but it is still supported and there are plenty of uses for it. I actually i didn't have much of a choice and had to find a way to make this work. This is why i'm sharing my findings with anyone else that has to deal with this kind of headache.
TL;DR: check http headers to see if service response is "Transfer-Encoding: chunked" (streamed) to you and if so, use transferMode="StreamedResponse" in your binding configuration.
So after Googling for days with no help, i spun up Fiddler for http traffic capture - this requires your WCF basic http binding configuration to proxy in to Fiddler (http://localhost:8888 by default, i think) and depending on where your target service resides you may or may not need to configure Fiddler's Gateway settings (corporate proxy, etc.).
This allowed me to see the raw text being sent between my client to/from their service; all payloads were coming in just fine, which meant, in my case, that the MTOM/XOP response from the service was being completely transmitted and that the WCF runtime was not interpreting the response correctly. Another critical thing i saw was that the Transfer-Encoding http header was "chunked" and there was no Content-Length header... this meant that the service was streaming the response, as opposed to a buffered response. Now a little side note: MS's WCF MTOM documentation has a call-out saying that you should always use "Buffered" as your transferMode in your binding configuration... but failed to mention that was really only applicable in Services, not necessarily clients!
So naturally, i simply went in to my config file, found system.serviceModel >> bindings >> basicHttpBinding collection, found my specific binding configuration and set transferMode="StreamedResponse" (because the 3rd party service was streaming my response back to my client).

403 Response from Power BI Rest API

I am getting a 403 response from the Power BI rest API and I am not sure why.
Here is the request I am making in cURL format(my actual web app is in Java):
curl -X GET -H "Authorization: Bearer accessToken" -H "Cache-Control: no-cache" 'https://api.powerbi.com/beta/myorg/dashboards'
I have given all Power BI Service permissions on my app in the azure management portal.
Do I need to replace 'myorg' with an actual org name? If so where would I find my org name? What am I doing wrong? This request seems to work for me in Aipary.io so I think it has something to do with my app not the request.
I have tried this request with both an admin account and a regular user and I get 403 responses for both of them.
I have also tried removing the Power BI Service permissions from the app with my admin account and then adding them again. That didn't work.
It seems to be that the 403 response was caused by the request in cURL missing some required parameters. The 403 response should show the error information that might be ignore.
Per my experience, I recommand you can try to use the GUI tool Postman in Chrome for requesting the APIs like cURL.
For checking the issue, you can follow the toturial https://powerbi.microsoft.com/en-us/documentation/powerbi-developer-authenticate-a-web-app/ to make sure the request required parameters correct.
However, according to your description for the issue, I can't locate the problem whether the prepare steps cause. So I suggest you can try to review the complete toturial https://powerbi.microsoft.com/en-us/documentation/powerbi-developer-steps-to-create-a-power-bi-app/ to be sure the every step is correct.
Hope it helps. Any concern, please feel free to let me know.

JAXWS. ClientTransportException: The server sent HTTP status 403

I've generated classes from wsdl with wsimport, wsdl location: https://somehost/wsdl. There was no problem with generation.
But when I tried to send soap request, I've received exception:
com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 403: Client certificate required
I find out, surfing the internet, that I have to add certificate in my keystore. I've done it, but this doesn't help.
And I have no idea what to do or even what to google.
Can anybody help me?(
It sounds like a mutual authentication problem.
The server is requiring that your client use a known digital certificate to sign your messages and send that information within the request. It is like a user/password mechanism, but you and the server agree to use a known key-pair for identification.
This situation usually means that the web service server administrator will generate a key-pair and send the private part of the certificate to you.
But you can send the public certificate for him as well if you created it yourself. The server must have access to the public certificate, and it maybe you will have to publish it to a Certification Authority. In some cases it has to be a commercial certificate (you will have to buy it).
You will then use the private key to digitally sign your messages.
I've found some links that may help:
Authentication Mechanisms
Java client for the X.509 secured web-service
Java HTTPS client certificate authentication
If you already did those steps, then something is wrong with your implementation or the certificate/keys provided are invalid.
I recommend you to use a mock server to make sure you are implementing the client authentication properly before you try to connect to the real service. Making it to work locally will set the knowledge you need to call the real functions. You can also ask the web service administrator to send you debug information.

Jersey client: how to access an HTTPS service

I have been googling a lot for this problem. There are many relevant answers, but I simply didn't find one that gave a complete view IMHO. So, here I am.
The statement of problem is as follows. Given the API information of an HTTPS service, including URL and any required HTTP headers and body format, how do you use a Jersey client to access the service? Note that the statement doesn't assume the client side has any other information from the target service beforehand.
As we know, when a web browser tries to access an HTTPS site, behind the scene, the browser will first get a certificate and a public key from the site. Then, if the browser trusts the certificate, it will use the public key to encrypt the actual request and send it. I have found many examples that explain how to use Jersey client for HTTPS given a truststore that incorporates the certificate and the public key. However, what if the truststore is not available yet? Can we use Jersey client, programmatically, to get the site certificate and public key, and use them to send the actual request, as a web browser does?
Thank you very much.

How to check if url exists over https in java

I know how to check if a url exists in using, see following posts.
Check if file exists on remote server using its URL
How to check if a URL exists or returns 404 with Java?
The problem is if a ssl https url exists, i tried all suggestions in the above threads, and while they work fine on normal http urls, none of them work on a https file.
Is it not possible?
Suggestions?
The normal methods that work with "http:" URLs should also work with "https:" URLs. If they don't, then the probable cause is not the code but something else:
The URLs might use a SSL certificate that is not acceptable to Java. It might be self-signed, it might use a root certificate that your JVM's certificate store doesn't include. It might be the wrong certificate for the site.
It might be a problem with your JVM's proxy configurations. (You can't proxy HTTPS).
The remote site might simply not be listening for HTTPS requests.
The remote site might filter HTTPS requests based on header fields; e.g. the agent header.
To help us help you find the problem:
tell us what URL you are trying to access,
tell us if the URL works for you using a web browser,
if there are exceptions, show us the stacktraces.

Categories