Is it possible to use java socket API to read content of a webpage, ex: "www.yahoo.com"? Can somebody here show an example?
And how about reading content of a page protected by the web app login screen?
Thanks in advance,
dara kok
It's possible but not advisable. The webpage is returned using HTTP, which is more than just a stream of bytes. This means that in order to use a socket you application would need to understand the instructions in the HTTP responses and behave accordingly.
To programitically access a webpage use Jakarta Commons HTTP Client.
With regards to secure webpages, it will depend on how they are secured, however given HTTP Client can maintain cookies you should be able to perform the login through code too.
Further to Nick's answer (i.e. use the Jakarta commons HTTP Client). The login security depends on how the login page is implemented, if it is an apache .htaccess secured site you will need to place username/password information in the request header. Alternatively (and generally more usual), if it is an html form, you will need to deconstruct the form fields from the original HTML and send those as key/value parameters in the http GET/POST request
Related
I have written a simple HTTP server using Java and want to send some additional information (puzzle parameters and a small puzzle solver program) to the client i.e. a regular browser.
Similarly, the browser is also supposed to send information (solution) back to the server.
Is there a way to do this by just transmitting this information over the HTTP headers?
Thanks a lot
the headers are usually used to add http protocol relevant information.
You should probably use either the body of the response or cookies to add the needed information.
Adding a cookie is done using the header so it kind of fits what you are asking for.
But I wonder why you need to put it in the header? it seems like what you are asking for is url parameters (client to server) and response body (server to client).
I need to send a request from a servlet to an application running in other environment (IIS) with certain information in custom headers.
I know redirecting doesn't send the headers and getServletContext().getRequestDispatcher(url) is to be used in the servlet's context only. Has anybody made this work in some other way? I was thinking in using HttpURLConnection, but would it finally redirect the browser to the targeted app ?
Thanks in advance
You can't redirect from your servlet to the external server and keep the headers, and you can't forward the incoming request to other context.
What you could do, is to use the HttpURLConnection (or other http client library such as HTTPClient) to make the request (with the custom headers you need) to the remote server and, once the operation is complete, redirect the user to the external site (customm headers are not set in this redirection).
This is a little tricky, if you elaborate your question (what do you really need to do) we can probably think about other alternatives.
AJAX? You can send some JavaScript code to the browser which sends a request to the ISS and handle (shows) its answer. It's possible to set http headers with XMLHttpRequest but it needs client side JavaScript coding and you have to find a way to send cross domain requests.
I am working on small Java project to programmatically connect to a website with username/password, after login, browse to different links on the site to download some data. First, I need to connect to the website with username/password,
second, while I keep the session open, go to other links to download data.
How do I do this in Java?
Any help will be highly appreciated!
Check out the Apache HTTPClient, it can do all this for you.
Edit: Apache HTTPClient has authentication and cookie handling features included, which will save you a lot of work doing this yourself.
If you want to extract some data HtmlUnit can help you a lot it can manage the authentication and also help you with data extraction.
Investigate with your browser how the web page submits the username/pass data? HTTP Form POST, Ajax, etc..? Use a plugin like Firebug to see network traffic.
You can use URLConnection to create HTTP requests. You will neet to simulate a username/pass login and remember the cookie for use in consequent HTTP requests to simulate a session. Here are some examples: send HTTP POST request, get a cookie, send a cookie.
Is there any web language that allows the client itself to create HTTP posts to external sites.
I know that JavaScript does this with XMLHttpRequest, but it does not allow cross-domain posting, unless the recipient domain wants to allow the sending domain.
I want to post data to an external site (that I don't control) and have the request be authenticated with what the client's browser already has (cookies, etc).
Is this possible? I tried cURL but it seems to make a server HTTP post, not a client HTTP post.
Edit:
A bit more insight of what I am trying to do:
I am trying to POST JSON to the website using the user's session (I said cookies but I believe they are PHP sessions, which I guess I still consider cookies).
The website does NOT check the referral (poor security #1)
I can execute javascript and html on the webpage using my personal homepage (poor security #2)
The JSON code will still work even if the content-type is form (poor security #3)
There is no security checking at all, just PHP session checking.
The form idea is wonderful and it works. The probably again is that its JSON. So having sent postdata as foo={"test":"123", "test2":"456"} the whole foo= part messes it up. Plus forms seem to turn JSON into form encoding, so its sending:
foo=%7B%22
test%22%3A+%22
123%22%2C+%22
test2%22%3A+%22
456%22%7D
when i need it to send;
{"test":"123", "test2":"456"}
So with everything known, is there a better chance of sending JSON or not?
I don't think so: You won't get hold of the user's auth cookies on the third party site from server side (because of the Single Origin Policy) and you can't make Ajax requests to the third party site.
The best you can do is probably create a <form> (maybe in an <iframe>), point it to the third party site, populate it with data, and have the user submit it (or auto-submit it). You will not be able to get hold of the request results programmatically (again because of the Single Origin Policy), but maybe it'll do - you can still show the request results to the user.
I think for obvious reasons this is not allowed. If this was allowed what would stop a malicious person from posting form data from a person's browser to any number of sites in some hidden iframe or popup window.
If this is a design of your application you need to rethink what you are trying to accomplish.
EDIT: As #Pekka was pointing out I know you can submit a form to a remote site using typical form submits. I was referring to using some client side ajax solution. Sorry for the confusion.
You should follow the way OpenID and other single-sign-on system works. How openID works is your website POSTs some token to openID service and in return gets authentication result. Refer How Does it Work? section here
Yes, you can use a special flash library that supports cross-domain calls: YUI connection manager
Added: not sure about the cookie authentication issue though...
The client cannot post to an external site directly; it's a breach of basic cross-domain security models. The exception is accessing javascript with JSONP. What you describe would require access to a user's cookies for another website, which is impossible as the browser only allows cookie access within the same domain/path.
You would need to use a server-side proxy to make cross-domain requests, but you still cannot access external cookies: http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html
Can anybody explain the following:
The unique JSESSIONID generated by the
server for every client is exchanged
between the client and server using
Hidden form field
Thanks
What server technology is this? Technically, you could do some form of session tracking if a form was posted every request, but I've never seen someone attempt this. It isn't something in any Java EE API I've come across.
The Servlet specification only lists three session tracking mechanisms: HTTP cookies; SSL sessions; and URL rewriting.
This is not true. It's been exchanged as a cookie.
Cookies are specified in the HTTP request and response headers. To see it yourself, use some tool with which you can view those headers, such as for example Firebug or Firefox Web Developer Toolbar.
Maybe you confused it with the "view state" which some MVC frameworks indeed passes as a hidden input field.