I am trying to add proxy support to my Jersey Client.
I use org.glassfish.jersey.core:jersey-client:2.11 but I can switch to any Jersey Client 2 version.
Currently the client uses the default Jersey connector which does not support proxy AFAIK.
I have tried solution described here How to add a http proxy for Jersey2 Client
but then when sending a multipart content I get:
org.apache.commons.fileupload.FileUploadException: the request was rejected because no multipart boundary was found
and the WARNING in the client:
Aug 10, 2015 5:10:32 PM org.glassfish.jersey.message.internal.HeaderUtils checkHeaderChanges
WARNING: There are some request headers that have not been sent by connector [org.glassfish.jersey.apache.connector.ApacheConnector]. Probably you added those headers in WriterInterceptor or MessageBodyWriter. That feature is not supported by the connector. Please, do not modify headers in WriterInterceptor or MessageBodyWriter or use default HttpUrlConnector instead.
Unsent header changes: [MIME-Version, Content-Type]
Also Jersey Client 2 documentation mentioned the issue (https://jersey.java.net/documentation/latest/user-guide.html#d0e9179)
Warning
Do not use ApacheConnectorProvider nor GrizzlyConnectorProvider neither JettyConnectorProvider connector implementations with Jersey Multipart features. See Header modification issue warning for more details.
What is the way of configuring Jersey Client 2 to support both:
Sending multipart content (for uploading files on the server)
Proxy server support
?
PS. Maybe there is a way of adding proxy support to the default jersey connector implementation?
I figured out a way to work with apache connector(connectors other than default httpurl connector) as well as multipart feature. If I add boundary to content-type when build the request with Invocation.Builder, it works.
My code is as follows.
MediaType contentType = MediaType.MULTIPART_FORM_DATA_TYPE;
contentType = Boundary.addBoundary(contentType); // import org.glassfish.jersey.media.multipart.Boundary;
Response response = builder.post(Entity.entity(requestPayload, contentType), Response.class);
Related
I'm calling a SonarQube API using JSONP module.
this.jsonp.get('https://sonarqube.com/api/projects/index')
.subscribe(res => console.log(res));
I previously used Http module of Angualar2, which caused the browser to throw the error
Origin http://localhost:4200 is not allowed by Access-Control-Allow-Origin
To overcome this problem I found out that you could use JSONP or CORS or launch chrome with --disable-web-security of which I could find sufficient typescript support to get started with JSONP. But I later found that JSONP expects MIME-type to be application/javascript when I got the following error
Refused to execute script from 'https://sonarqube.com/api/projects/index' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
Is there a way to force JSONP module to fetch JSON data and parse it successfully?
Solution 1: Enable JSONP in Server
I found out that this isn't possible. JSONP is just one way to get over the Cross-Origin-Requests problem, but it requires a modification to the server configuration/implementation to serve JSONP data (MIME-type: application/javascript).
Solution 2: Enable CORS support in server
CORS is a more recent solution to the Cross-Origin-Requests problem. It can be resolved by adding the following headers to the server:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Headers: Authorization, Lang
Solution 3: Using a reverse proxy
One suggestion I came across in my search was to use the server to fetch the Cross-Origin-Request. I didn't have control over the server code. Then I came across the concept of Reverse Proxies, found the cors-anywhere package in an angular forum. The reverse proxy fetches these resources on behalf of your front-end and adds the CORS headers to the proxied request.
Using soap ui 4.6 ,I need to authenticate rest api using certificate and username/password and then i have to get the session id(cookie) and work with it for other operation.How can i do this? any reference?
I do this manually in order to avoid any unknown cookies and/or "magic" that the session manager might pass along. Here is my Java RestAssured example and the equivalent SoapUI request headers:
response = given().cookie("SESSIONID", "12345").cookie("ABC_123", "abcde").header("CLIENT_ID", "aaa123");
In SoapUI set these headers:
Name Value Style Level
CLIENT_ID aaa123 HEADER RESOURCE
Cookie SESSIONID=12345; ABC_123=abcde HEADER RESOURCE
i.e. you put all the cookies in correct format in single header called "Cookie". Standard http stuff, but nobody really gave this answer yet.
I have WSO2 API Manager configured and everything seems to work fine.
The only issues bothering me is that in case of an Auth exception, the API manager always returns the response with XML content type, e.g.,
<ams:fault xmlns:ams="http://wso2.org/apimanager/security"><ams:code>900904</ams:code><ams:message>Access Token Inactive</ams:message><ams:description>Access failure for API: /exchange, version: 1.0 with key: 1139a466ebfd825aca953ad7259b9f45</ams:description></ams:fault>
In case of client communicates with my web service with JSON format, the XML response will look a little bit strange.
Is there any ideas how to make API Manager provide error response in JSON format?
This has been addressed in recent versions of API Manager. Auth errors can be set to json format by adding or updating the error_message_type property in WSO2HOME/repository/deployment/server/synapse-configs/default/sequences/_auth_failure_handler_.xml:
<property name="error_message_type" value="application/json"/>
I've found this also requires JSONBuilder and JSONMessageFormatter to be selected for the json content type in axis2.xml (which is the default setting).
For older versions, this article explains how to manually do the same.
We are using wso2 api manager to manage our REST apis. The default configuration in the api manager comes with org.wso2.carbon.relay.BinaryRelayBuilder for application/json content-type. I expect the whole data treated as binary and added to a payload node in the soap body. But when we try to send a request to the api manager, the whole request is converted into xml and wrapped by SOAP envelope. This was confirmed by logging the request inside the in-sequence of the proxy created by the api manager for this api, we could see the whole json request converted into xml.
Why does the API Gateway convert from json to xml when relay is used? Is there any configuration that we have to do to disable this xml processing in api manager?
Note: One of our APIs is a high throughput API. This json to xml conversion and then xml to json conversion will add extra load to our processing.
In which version of APIManager you see above issue? If you enabled the Binaryrelay message builders, you will only see the binary message content, when you use log mediator inside any sequence.
Did you set the content type of your request properly, when you do POSTing?
Please check the relay module conf is added in your axis2 configuration (axis2.xml)
<module ref="relay"/>
I have found the solution for this. The binary relay happens in the API Manager only if we disable the relay module conf in axis2.xml.
<!--module ref="relay"/-->
By default it is enabled in version 1.3.0 and disabled in 1.3.1. But to make relay work for application/json content-type we have to disable this in addition to using the message builder/formatter of Binary relay. Not sure if this impacts anything else. This may be a bug in the API Manager.
Ok so I have a WCF ODATA service hosted locally for testing purposes. Then I have a Kendo Grid trying to query the service using a Kendo Datasource configured for ODATA exactly like the demo!
On the deployed service, I also implemented the "JSONPSupportBehavior" attribute and class that everyone is talking about!
Still I get this in Fiddler : A supported MIME type could not be found that matches the acceptable MIME types for the request. The supported type(s) 'application/atom+xml;type=feed, application/atom+xml, application/json;odata=verbose' do not match any of the acceptable MIME types 'application/json'
Is this IIS issue now or something else? This is driving me crazy!
This is a change made in the WCF Data Services release. In order to get JSON response back (or JSONP) you need to send Accept header with value application/json;odata=verbose. Pure "application/json" is now reserved for the soon to be coming JSON Light format.
See http://blogs.msdn.com/b/astoriateam/archive/2012/04/11/what-happened-to-application-json-in-wcf-ds-5-0.aspx for more details.