I have the scenario to the HTTP request which is hitted from the browser address bar and i need to redirect to different URL on the client side.
Is there any way to Abort the HTTP request and redirects to the new URL.
No, if you were able to do it, it would be a large vulnerability. The reason being is that the http request would signify request headers being sent back to your browser, indicating that you're already on your way to the other site. If this could be done via javascript, it would definitely be a hack, as it would allow you to redirect a site such as fakebank.com instead of mybank.com.
You cannot do this using just javascript.
You need to capture the request on the server side and make a 3XX request setting the Location http header to the URL you want to redirect your users to
Related
I am making an HTTP request from Java using
HttpURLConnection con = (HttpURLConnection) url.openConnection();
The library used is org.apache.http.client
For some reason, the body tag in HttpPost is empty when it reaches the endpoint. (RequestParameters).To me, this is a separate Stack Overflow question. I had to send the request by querystring.
The query string parameters contain the username/password credentials as it request for a token. I am afraid the credentials will be visible as it is done over a query string though request will go over HTTPS (and HTTPS is encrypted). But I would have been less concerned if the request was POST with a payload.
I don't want anyone to view this request i.e the browser comes to my mind. The HTTP request does not show on the address bar or in Chrome Inspect (Network tab).
Nevertheless, can Apache HTTP requests done from Java, in theory, be inspected by browser? (regardless of POST with payload or querystring)
The answer is No, in my knowledge. You will be able to view the requests originating from the browser tab in developer tools.
If you want to see the network calls originating from your whole system, you can use tools like Charles Proxy.
I am using java to connect to a website which has a form of type "multipart/form-data". It asks a user, pass, and file to upload.
When i run my java project, the response i get is "200". According to w3.org, anything in the 2xx class of HTTP responses indicates that "the client's request was successfully received, understood, and accepted."
My question is, if this is the response code i get, can i assume that the file was DEFINITELY uploaded to the site, and that there was no error? To put it in other wording, is the code "200" a guarantee that the file i sent is on the server, or is it just indicating that my POST request was understood?
Thank you!
The HTTP status code 200 states that
The request has succeeded.
The server is therefore telling you that the request you made was successful. However, this doesn't tell you anything about what the web application did. It's up to the web application itself to tell you, possibly as part of the HTTP response.
You should check the web application API or specification and interpret the HTTP response accordingly.
Hi i am running a server socket created in java that accepts requests from a client that uses HTTP url to connect and send web requests.
client does this:
URLconnection.opeonConnection(new Url(www.hello.com/hi));
on my server socket it retrieves a Socket object.
is it possible to retrieve the url www.hello.com/hi url that was passed to this socket conection?
Probably, by parsing the client's HTTP headers:
You can get the "/hi" portion with some work. The URL Connection class will use the HTTP protocol to submit some HTTP headers, along with a GET request as "GET /hi HTTP/1.1". The "/hi" portion comes from the URL.
The "www.hello.com" part might be more difficult. The browser will provide the host and port (if port is given) portion of the URL in a "Host: " header. It's likely that your networking infrastructure may contain proxies or load balancers that forward the request on to the final backend server, and if the proxies aren't configured correctly, they won't maintain the original host header. Try it yourself, and talk to your network administrators if it's not working as you expect.
If you want to see what the URL connection class will send to your server you can get an idea by pointing your browser to this URL: http://request.urih.com/. The "request header: raw source" section shows you the HTTP headers sent by an HTTP client (your browser).
The "HTTP Headers for Dummies" web page is also a good introduction to HTTP headers
Yes it is possible to get the String but not the way you likely want it.
You can implement a HTTP-Server (see RFC 2616). But it is likely that you don't want this.
You can also use a Servlet container like Tomcat or Jetty and write a Servlet to use HTTP. With this the Servlet container does all the protocol and you can concentrate on doing the business logic.
As you state you're building a proxy, you're already asking the wrong question.
An HTTP proxy only has to deal with one command: the CONNECT command. You just have to:
Read this one line from the client.
Connect to the target indicated in the command.
Reply with success or failure.
If success, start copying bytes in both directions.
But I don't know why you're even implementing an HTTP proxy when there are dozens of free working ones already in existence.
In in the interface Socket there is getRemoteSocketAddress(). It returns a SocketAddress, and if the implementation of SocketAddress is InetSocketAddress, try to call getHostString().
SocketAddress address =yourSocket.getRemoteSocketAddress().
String address=((InetSocketAddress)address).getHostString();
Hope it helps.
I'm attempting to use Nexmo.com to send and receive text messages. Sending works fine, but I am having some issues receiving messages.
My issue is with the Callback URL and what format that page should be in. Nexmo's documentation is here and says this
Inbound Message
If you have purchased long virtual numbers, you will need to set up a CallBack URL for inbound to which we will send a request for each incoming message. Nexmo will be expecting response 200 OK, or it will retry.
The request parameters sent via a GET (default) to your URL include the following parameters.
Am I missing something extremely simple? Is there somewhere that I haven't found with an example of a Callback URL page? Thanks for any help!
Edit: For clarification, I'm using Nexmo's provided java library, but since their api is all built around URL's the java program simply visits a URL to send the message. Here
are their provided libraries
Not sure if I've understood your question.
Generally, if you want to receive messages, you have to setup a service on your server, with a callback url, say http://api.example.com/sms/
Then you setup this callback url in Nexmo. After that, Nexmo will access your server through the callback url, and send parameters via GET method.
And your server receives those info, and response 200 to Nexmo.
I am actually trying to send SMS using CDYNE and their API. To do that, I am using Java and HttpGet and HttpClient object (Httpcore and HttpClient libs). I am sending the request to an https URL, sending the parameters like https://www.example.com/SecureREST/SimpleSMSsend?PhoneNumber=ABC&Message=XYZ
Would it be a security issue that I am using a GET request and that all parameters are in the URL it self? What if the content of the Message parameter in the URL contains sensitive informations? Could someone sniff the network to get hold of the content or is is safe since the request is sent using HTTPS?
My believe is that only the www.example.com is visible during the handshake process and that once this is done, everything is encrypted but I just want to make sure.
Wikipedia is pretty clear about this:
Note that when a client sends an HTTPS request, the hostname and port of the URL are unencrypted... However, all other parts of the HTTPS request, including the URL path and query parameters, can only be decrypted by the destination site or by an interposing intermediary that terminates the HTTPS connection on behalf of the site.
So your belief is right. Only the hostname and port are openly visible; the rest of the URL is encrypted.