We have a Java based web application where we use HDIV as our security framework. Fundamentally our app does not have any form tags, rather we have many AJAX calls which brings JSON/HTML response with which the cards in the pages are constructed.
We are making use of POST requests while dealing with sensitive data. Those data's are sent in POST request body. In order to be security compliant we do not include POST requests URL in the hdiv:startPages and if we do that we are getting HDIV related exceptions in our error log saying that "HDIV_PARAMETER_NOT_EXISTS;" we googled around and found that it is expecting the state ID and from these URL's (https://github.com/hdiv/hdiv/wiki/Appendix-C:-Ajax and https://github.com/hdiv/spring-mvc-showcase/blob/master/src/main/webapp/WEB-INF/views/partialform.jsp)we figured out how the HDIV state ID can be added for AJAX end points.
But the catch here is if the state ID is generated and appended as a query parameter to the AJAX end URL then HDIV is not throwing any exceptions since it identifies the state ID parameter from the end URL. On the other hand if we try to add the state ID in the request body then it throws the exception stating that the "HDIV_PARAMETER_NOT_EXISTS;".
Precisely,
We are not suppose to include POST request AJAX end point in hdiv:startPages
In order to do that we should append the state ID as part of the URL
That state ID should be in POST request body and not as a query parameter in the URL.
HDIV exception is thrown when state ID is in the request body and works only if it is available as a query parameter in the end point. For POST requests generally it is not recommended to add a parameter as a query string value.
It would be great if some one could guide us in this regard.
Thanks!!!
Sai
Same issue was answered in HDIV's Github issue tracker: https://github.com/hdiv/hdiv/issues/83
I hope it helps!
Gotzon Illarramendi(HDIV Team)
Related
I need to send POST request through jmeter. I have checked the requests workflow through browser dev. tools. In my Post request I need to send form data and one string Query. Question is next - if i will add my string Query to URL will it work fine?
Example : somesite.com/something?refURL=someRef
If it is a POST request, usually any form data will be sent in the request body. Not like a query string in the GET request. But the format is same.
refURL=someRef add this in the parameters section.
Check here for more info.
https://www.w3.org/TR/html401/interact/forms.html#h-17.13
Why not? Query string and request body are different beasts and they are processed differently on server side.
Instead of asking this kind of questions, why don't you just record your test using JMeter's proxy server?
References:
URI Syntax - Query Component
HTTP Method Definitions - POST
Yes it will.
You can even use variables like:
/some/path?refURL=${someCalculatedRefUrl}
In Laravel we use routes to deal with HTTP requests from the browser.
We can route a request to a controller, do some logic and then return a response.
Now, we can send in variables encapsulated with braces {} and the response can be anything, so it seems to me that routing through a controller means that the the properties of the different request methods (POST, GET, PUT etc.) are lost.
For example I could send a POST request with URI example/{id} then put in my routes.php file
Route::post('example/{id}','SomeController#SomeAction');
Then I could do something in my controller with the variable $id and send a response.
On the other hand I could send a GET request with URI example/{id} and alter my route to
Route::get('example/{id}','SomeController#SomeAction');
The controller would give the same response.
So, am I right in thinking it does not really matter what request method is used?
Two parts of your question I can identify on a second read-through:
Request methods are not lost. You have access to them with $request->getMethod(). So a GET request will return GET. You also have the method isMethod('GET') available to you, which you could use to get a truthy value which would enable you to return a different kind of response depending on the request type.
With regards to the way you set up your URL, what HTTP verb you use does matter if you're creating a REST-ful web service.
I won't explain away what a REST-ful web service is (you can look it up), here is a couple of points from your example:
If you're getting some data, you ought to be doing a GET request. It is the verb to represent a read from a resource. If you had to send a lot of data - and your intention is to add data, you ought to POST it instead.
The URI should be meaningful in a way that best describes the resource you are manipulating.
Together with the HTTP verb, you can infer the implied action. So if you are POSTing to example/1, I might infer that (and this is a digression, actually) that you are attempting to update record 1 from an example resource. In reality, you would perhaps use the PUT verb (which handles update).
Behind the scenes, Laravel uses a POST request due to browser limitations but treats it as a PUT request server-side.
Of course request type does matter. When you want to hide some request data against user and dont show it in url for example:
?username="Admin"&nick="admin1" then u will use POST otherwise you can use GET. When you want get some data u will use GET but when you want to send some data then you should use POST instead.
So I looked at this post:
is an entity body allowed for an http delete request
Which seems to indicate that while it is 'ok' to do on some conceptual level, in practice it may not be doable because browsers just ignore it.
I have some express.js authentication middleware I need to get through, and I don't want to attach my user details to url params. All my other requests that need to authenticate attach these details to the body of the request.
Is there some way to force this? I saw some other posts where some people seemed to have success in passing a body with their delete request.
I am running a node/sails back-end. It always logs the body as undefined for a delete request. Is there any way to modify
The sails API pulls the id of the object to delete from the params, so we have to append the id to the url.
But if I want to pass some authentication details in a body for server-side verification before processing the delete request, I can't just stick them in an object as the second parameter of the delete request, like you can with $http.post.
Angular's post method automatically assigns whatever we insert as a second parameter to the body of the request, but the delete method does not.
Angular's $http.delete method does allow us to supply a config object as the second parameter, through which we can get access to the 'data' property. This is the same way post does it through it's second parameter.
So if we need to attach a body to a delete request we can use the following:
$http.delete('/api/' + objectToDelete.id, {data: {id: currentUser().id, level: currentUser().level}});
This will pass the object to delete's id in the url parameter, and my user credentials in the body as an object.
Honestly, everytime a trouble sounds like a "restriction of as REST", a rethink of the strategy and the philosophy might be a good idea.
I have some authentication middleware I need to get through
I don't want to attach my user details to url params
I'm not directly answering the question, but you should know that among the commons
URL parameters (or query, but URL anyway)
Body
there is a third option for "passing values to the server" :
request Headers
I'd just suggest to consider that third option to provide your credentials: request header.
Edit : following appendix would just apply to any "external" middleware, like a proxy server or whatever, not a true express middleware inside sails.js
In addition, that would be a good idea that your middleware stripped those headers before redirecting to the real action.
In Web API v2 when you supply data in the POST body that are not part of the model, they are ignored by the framework. This is fine in most cases, but I need to check this and return an error response, so the user doesn't get unexpected results (he expects these wrong parameters to do something...).
So how do I check for this? The model will be null, but when the framework has parsed the data and returned a null-model, I can no longer access the body through Request.Content. So what options are there?
One way is to derive your DTO class from DynamicObject. Check out my blog post: http://lbadri.wordpress.com/2014/01/28/detecting-extra-fields-in-asp-net-web-api-request/
In my Cappuccino frontend I'm using Ratatosk to make queries to a RESTful JSON-based API.
When I create a new resource with
[myNewResource ensureCreated];
my backend returns the status code 201 and a Location header with the URI of the newly created resource. The response body is empty. As far as I know, that's the way a REST API should react to successful POST requests.
But upon receiving the response, Ratatosk calls
- (void)connection:(CPURLConnection)aConnection didReceiveData:(CPString)data
(in WLRemoteLink.j) and tries to decode the response body. This throws an error because the response body is empty. As a consequence, the request is repeated infinitely.
How should I go about this? Am I supposed to return the whole resource in the response body?
EDIT:
Returning the ID in the response solved the problem, like
{"id":1}
Ratatosk expects the status code 204 (no content) if the response is to be empty. Otherwise it expects the full representation of the resource which was just created (which it uses to populate server side dynamic properties locally like created_at).