I have a code which does a POST to a URL. The code uses setFixedLengthStreamingMode since it knows the length of POST in advance.
I am having a situation where in some cases the URL could be redirected to something else and since streaming mode is enabled; its not able to follow redirect.
Is there any way to do a check before actually posting the data to see if URL is getting redirected or not? Or am I thinking in wrong direction?
In general, no, there isn't. In a normal web use case though after a POST request done from a submit form you should always get a redirect as per best practices, but this is far from guaranteed. For example, it can do a request if data is similar, and not do it if it is something else. It can always fail with an error.
For some limited use cases there might be some logic that is always followed, but that is case-by-case thing then.
From documentation:
When output streaming is enabled, authentication and redirection
cannot be handled automatically. A HttpRetryException will be thrown
when reading the response if authentication or redirection are
required. This exception can be queried for the details of the error.
So while the redirect will not be handled automatically, and even though you cannot really check for redirect beforehand, what you can do is that you can catch the exception and perform steps yourself based on that.
Related
we implemented a paymentmethod with saved creditcards and 3dsecure (SAP commerce/hybris), but it's not always working. Sometimes a nullpointer for the orderData is thrown, after returning from the paymentservice. The reason for this seems to be, that the user sometimes is anonynoums after the return, so the orderData isn't visible.(the orderData exists by the way)
But I have no idea why this happens. And like I said it only happens occasionally on prod, but when I debbuged local it happend most of the time. And at the paymenservice the payment is authorized.
But it's difficult to debug, because there aren't any testcards to test with 3dscure, so I have to use a real one everytime.
To be honest, I am not sure if I am allowed to show the code here, so please forgive me, for not showing it now (I didn't write it).
Are there any "common" mistakes/suggestions/best-practices or whatever? Or maybe just an idea?
Oh, and we don't face this problem with other returns like paypal.
It's a bit tricky, since I don't know the code, but here are some advices:
Maybe the Session Cookie in the browser is destroyed somehow? You can check with the Browsers developer tools if the cookie is contained in all requests (Network Tab -> Click on the Request -> Request Header). This can sometimes happen if you switch between http/https or multiple subdomains.
Bad timing with an automatic logout of the user?
Are you using multiple cluster nodes? Maybe the session is not yet synchronised between the nodes?
So there is an error.jsp page and I want user to occur on this page after he/she inputs invalid data.
Is it better to use sendRedirect or requestDispatcher.forward for redirecting to the error page?
I know, it may depend on whether I want to put some attributes to the request object and so on. And I'd prefer to use requestDispatcher.forward, but is it safe? Cause in this case after page refreshing the data will be sent to the server one more time. Yeah, it doesn't make any effect (insert, update, delete) on database since the data is invalid so the user occurs at the error page once again. But... idk, I feel like something is being wrong with the approach of using requestDispatcher.forward, even though it's kind of idempotent action.
So what do you think?
The important difference is :
The function sendRedirect will send a 302 response code to browser, then the browser will send another request to server again
https://en.wikipedia.org/wiki/HTTP_302
but the function requestDispatcher.forward is a server internal redirection, The browser has no feeling about it !
The title almost speaks for itself, but is valuable to always check isCommitted() on type ServletResponse? My particular example is in using a filter where I do the following if a user isn't authorized to perform a certain action (CSRF checks to be specific):
if (!httpResp.isCommitted()) {
httpResp.sendError(HttpServletResponse.SC_UNAUTHORIZED);
}
In this case, it almost feels like overkill that I've checked the response. My filter is at the top of the chain, there should be nothing before it that would commit a response (let alone allow the filter chain to continue if it did), but I can't help but feel like this is an assumption which in the name of good defensive programming I shouldn't be making. I feel like it's good practice to check the status of the response.
So, all of that being said, is it valuable to check the response at this point in time? And to maybe extend this further, is it good practice to always check this every time a response is modified? In my case, I can hardly find reason to support something other than an exception being thrown when a CSRF token does not match (assuming that would only happen in an attack scenario).
In general, based on when some code is executed you know that the response has not been committed. I would not add this check everywhere.
Some places I would add it:-
a piece of library code that might be called in various different contexts
exception handling code that might be reached before or after the response has been comitted
I have written test Filter (javax.servlet.Filter) and started to debug. And I was surprised that one refresh of html page calls twice method doFilter().
Could anybody describe me why it happens ?
Thanks.
Perhaps your filter was called also for static elements (images, etc.). Check your filter path declaration in web.xml.
One way to check what's really happening is to use either Fiddler or Firebug. Or both.
Another strategy to use is printing value of request.getRequestURL().toString() before doFilter(), so you can see what requests are being served. It's difficult to pinpoint why are you seeing 2 requests because the cause might be hidden somewhere in your environment or configuration.
Fire up Fiddler and watch the requests being made.
I had written java code for information sent and received for the server in bytes.The issues is how do i differentiate a HTTP Request submitted from a HTML form and a HTTP Request submitted from user. we are trying through refer in HTTP headers, but for the first request the referrer is null. hence this option is not feasible. is there any other API/other approach? Please let me know with a sample code...
thanks,
Ps
I understand the problem better now. The simple answer is no. The more complex answer is kind of, the best you can do is make an informed guess.
If the request does not have a Referrer header(1) then this might mean the user went to the URL directly (via typing it in to the address bar, or selecting a bookmark for instance). The problem here is that you're not guaranteed to receive that header, so you have to hope the browser is behaving.
Next, if the request type is a POST and the mime type is "application/x-www-form-urlencoded" or "multipart/form-data" then that is usually a form submission, i.e. a user has clicked submit, or similar.(2)
It is not (usually) possible for users using a browser to issue POST requests directly.
So that's a couple of basic rules to help you make a best guess, but there are so many things on the browser side that can mess with this logic I honestly don't think you'll find something that'll help you accurately.
Here's the algorithm at a high level:
When generating the HTML form, generate a random number/String/GUID and embed it in the form as a hidden input. Store this random value server-side (in application context, in a LinkedHashMap so you can set a maximum size/MRU cache, in some sort of cache solution, etc.)
When processing the form request, check for the presence of this random token.
If the request contains the random token, then source = HTML form
Else, source = human
You could also set cookies when sending the original HTML form, check for their presence on the postback; put some data in the Session object, etc; these are all variants on the same idea.
If this is for security reasons, then this is not possible. Anything the browsers sends to you, can also be send by the user.
But unclear is what you mean by send by the user.
Like Brindy said. Check the method, if its post check the mime type. It is as accurate as you are going to get. Unless the user is a professional he will not know how to fake a form submission, and most apps that use post to communicate that are not browsers will specify a different mime type.