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.
Related
I am trying to get an access token via RestTemplate.postForEntity().
myRestTemplate.postForEntity(authBaseUrl, request, Object.class);
I have a specific class for it, but let's use now a simple Object as type. It contains an access_token field.
It works, because I can get response, but the length if the access tokens (which is a string)
is 1196 character long. And I can get the same length in Postman too.
But if I use the intelliJ built-in REST client, the length is 1199.
Only the token from the intelliJ rest client works (So the longer).
Because I always get a new access token, it is impossible to get the same token twice.
How can I debug it?
What could be the problem?
Is the code that generates the response available to you? if so in your response add a header content-length so you can see what the server sent and what you received. Also, debug the server side and see what is being generated. In addition take another 3d party Http client and test it with this client see if you see a difference. The Http clients that you can try are Apache Http client, OK Http client, or my favorite - a very simplistic client written by me as part of my own Open Source MgntUtils library. Here is the Javadoc for my http client Here is a link to a similar question where you can get the references for any of above mentioned Http clients: How to check the status of POST endpoint/url in java
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
I am trying to implement sample spring boot project and to ensure my endpoints are working properly, i'm using POSTMAN. When using POSTMAN , I am not able to see the response(i.e in Pretty) for a POST request. But the Status is 200 OK and I am able to see the result using GET request.
No Pretty response for POST request
GET Response ensuring that the previous POST request works fine
And my controller code is the following
#PostMapping("/message")
public Message createMessage(#RequestBody Message message)
{
return service.createMessage(message);
}
Can anyone help me to find out why I am not able to see the result while using POST method please?
Like Rafael says it is good to return a Response with the object entity. I haven't been working with Spring myself but with JavaEE and in JavaEE it is perfectly possible to return the object directly without using a Response. I use Responses anyways though, because it is much nicer to work with, and you can create your own custom responses and status codes.
Maybe check if your createUser service actually returns a message.
I don't know much about Spring, but usually what works for me is using a ResponseEntity as the object returned by the function. Also, maybe you should use #RestController as the annotation to your class controller
#PostMapping("/message")
public ResponseEntity<Message> createMessage(#RequestBody Message message)
{
Message msg = service.createMessage(message);
return ResponseEntity.ok(msg);
}
I setup a GET scripted rest API. However, when I try to send a GET request with a body, ServiceNow (before it hits my code) complains that GET is not allowed to have a body.
Is there a way to disable this restriction? For now as a temporary workaround, I converted the request into a POST. However, this request does not change any state, so I believe it should be a GET. The request only searches for existing items.
GET is used without body, any configuration of a GET is in the URL and header. A query URL looks like this:
https://instance.service-now.com/api/now/table/problem?sysparm_query=active=true^ORDERBYnumber^ORDERBYDESCcategory&sysparm_limit=1
See the documentation here:
https://developer.servicenow.com/app.do#!/rest_api_doc?v=madrid&id=r_TableAPI-GET
Generally it's OK to use a POST to get data, graphQL does this for example, but i think SNOW is configured for GETs only.
I'm developing an iOS app that makes frequent requests to a web server, and I'm using AFNetworking (which I very much like). However, I'm running into a problem with authorization that I just can't solve.
The server requires me to provide an authorization header in order to get the response that I want. Specifically, the authorization headers should be like so:
Authorization = "ApiKey some-user-name:someNumericalApiKey"
I'm using AFNetworking throughout the project, and everything works fine, except for this authorization issue. I'm using the following code:
[myClient setDefaultHeader:#"Authorization" value:#"ApiKey some-user-name:someNumericalApiKey"];
where myClient points to an AFHTTPClient object. Strange enough, when I log the request in XCode using AFHTTPRequestOperationLogger, the logger claims that I have the correct headers set. However, the authorization header does not seem to reach the server - I can't see it in the server log.
To isolate the problem, I've tried to make the exact same request using good old NSURLRequest, as well as curl, and the requests library in Python - all of these work fine, i.e. the authorization header is sent & received (i.e. I can see it in the server log), and the server response is what it should be.
If anyone has run into the same problem (and has found a solution) I would very much appreciate to hear from you.
Thanks.
Sometimes (especially with Django) this is caused by redirection stripping of header parameters. For instance, /Object redirects to /Object/ in the background and removes the necessary auth parameter during the switch.
If you're using AFNetworkActivityLogger with level AFLoggerLevelDebug then you should be able to check this out in the console. If you see a POST request with /Object and the response with /Object/ then this might indicate redirection stripping is taking place.
If you construct your operation manually then the defaultHeaders are not applied, that might be the cause of your problem.