TL;DR:
Does stubby4j request proxying functionality support the setting of additional query params with the request which is being proxied?
Details:
I am using stubby4j HTTP stub server, the latest version (i.e.: v7.3.3) to proxy requests to another real live service when my request did not match any of the configured stubs.
I am interested to know if it is possible to pass in additional query params to the live service with the request which is being proxied?
In the official docs of the stubby4j request proxying behavior (https://stubby4j.com/docs/request_proxying.html) there is nothing mentioned about it and from what I see in my own testing, I do not think this is supported. But, I still wanted to ask on SO to check if I am simply doing something wrong.
You are correct, the the setting of additional query params on the request being proxied is not supported currently.
As per the aforementioned docs, the additive strategy only supports the setting of additional HTTP headers, which are specified in the headers property on the proxy-config object in your YAML.
But, it is pretty straightforward to add the addition of query params behavior. Feel free to raise a feature request at https://github.com/azagniotov/stubby4j/issues/new/choose
Related
I have a datasource that I can access remotely with a POST request (including an API key and user ID as data in the request).
Is there anyway to configure Prometheus to scrape this datasource? Preferably without any additional software.
I think not using scrape_config without a proxy (or additional software) unless the datasource is accessible using one of the service discovery targest listed in Prometheus configuration.
If you need to use a proxy, this should be straightforward.
You'd need to construct an out-of-band HTTP server defined as the proxy to accept proxied (GET) requests from Prometheus, possibly1 (!) injecting the API key and user ID, do whatever's necessary to respond to Prometheus' GET with a list of metrics in the expected exposition format returning these as the scrape response.
1 - unless you can wrangle your inputs as HTML params, or as basic_auth or authorization headers.
I want to make a Post to write some data into the database, but all needed information is stored on the server, so my Post service requires no body:
#PostMapping("foo")
public #ResponseBody
RestResponse writeFoo() {
// WRITE AND RETURN
}
If I try to make a post request to this service I receive 401 even if I pass a valid token. If I change my exposed service to a GetMapping all works as expected. It seems that I can't manage a Post request with an empty body.
I've tried adding some fake parameters as
RestResponse writeFoo(#RequestBody(required = false) String fake)
but without success.
Any idea?
The issue you explain is most commonly the cause of bad (or missing?) configuration.
Pay attention that i.e. GET method is allowed by default by your REST API, while you need to specify other method types (i.e. PUT and POST), otherwise it won't work out of the box due to CORS.
The part where GET method works while POST method doesn't is a strong hint towards missing/incorrect CORS configuration. You can fix it quickly by adding some CORS filter and setup your response headers.
The official documentation should give you a good start, if you don't know where to look for: Spring docs - enabling CORS
UPDATE:
The issue is successfully resolved, check comments section for more info.
Short story - back-end configuration for CORS/CSRF token was set up correctly in this particular case, the issue occurred due to missing header (CSRF token) on the angular/front-end part of the webapp.
I send a curl command with OPTIONS request method to my dropwizard application. I get a 200 Ok and POST and OPTIONS methods allowed as response.
How do i stop this from happening for security reasons as this provides some info about what are supported.
I tried implementing a custom request filter that responds with 405 not allowed for options method and added to a resource using NameBinding and but I think OPTIONS request does not reach at that point and so I am still getting 200OK and the same POST, OPTIONS plain text response.
I also tried using CrossOriginFilter.class in environment.servlets.addFilter() and configured it to not allow OPTIONS request. but that also did not work.
I got another post here :
Disable OPTIONS Method Jetty Server
but how do i achieve this in dropwizard via java code ?
You can disable the OPTIONS request on a global application level in DW by specifying which methods are allowed on the YAML configuration file:
server:
allowedMethods:
- GET
The applications is now returning 405 on all OPTION requests.
I figured it out,
In context of dropwizard:
Two ways to achieve this are
[Easy way] Create a request filter and filter based on a list of URLs that you want to disable OPTIONS request.
[Cool way] If you want to do with an annotation based filter like #OptionsFilter on a specific API resource method.
Detailed 2nd method:
First , you need to extend ApplicationEventListener and register all such methods
and during APPLICATION_START event (using reflection).
Then, you also extend RequestEventListener and listen to the event and then find the method from the uriInfo which you get in request context and then check in the list of methods that you created at application startup. For more sample implementation, see how #UnitOfWork annotation works and sets the SessionFactory for a resource method.
Since the Marvel api
must pass hash and time stamp as parameters, then the url actually will change at every request. Just like this: https://gateway.marvel.com/v1/public/comics?apikey=xxxxx&hash=xxxxx&ts=xxxx
And Okhttp's cache will work based on the same url, otherwise etag won't be useful.
Is there a solution to this?
Your best option is to bring it up with the API’s designers and explain why it’s cache-hostile. Browsers won’t cache these successfully, for example.
Once you’ve done that, you can use a network interceptor to add the cache-breaking query parameters to your outbound requests. That way requests that don’t need the network have cacheable URLs.
I want to modify HTTP requests headers using an Internet Explorer Browser Helper Object.
I basically need to change a few headers for every request, and then modify the response before it returns to the browser.
I tried using the OnNavigate2 events, but those don't even give you access to all of the headers.
I tried making an Asynchronous Pluggable Protocol, but then I don't really have access to the default HTTP implementation, and i can't override the default HTTP requests.
Do you have any idea how this is supposed to be done?
I prefer C#, but could use C++ if necessary.
It can be done with URL monikers.
There is an implementation of something like that by a guy called Igor Tandetik.
You can find links to the code in: microsoft.public.inetsdk.programming google group - just look for PassthruAPP.
(I would have posted a link but apparently new users are not allowed to do this)
It doesn't directly support modifying the response body though.
You will have to insert a hook into the IInternetProtocolImpl::Read method.
The easiest way to do it is to use an http proxy to intercept everything the way Fiddler does.
See this description of the Fiddler PowerToy (Part 1).
It seems that you can only modify CUSTOM headers by using the headers parameters of the BeforeNavigate2 event. Not all the headers are accessible. This is a way to try to minimize the potential of the BHOs to act as a Trojans. Use a HTTP proxy instead.