As per title really I'm wanting to send a custom HTTP post request to a web server and I have little experience in this area. The web server uses an LDAP server for access control (not sure if that's important) for which of course I know the username and password. Could anyone flesh out some code to do this or at least get me started?
Edit for one of the comments, the server is running a LAMP stack with PhP 5+ and Apache 2+
You can use HttpClient module from Apache.
Although the java.net package provides
basic functionality for accessing
resources via HTTP, it doesn't provide
the full flexibility or functionality
needed by many applications.
HttpClient seeks to fill this void by
providing an efficient, up-to-date,
and feature-rich package implementing
the client side of the most recent
HTTP standards and recommendations.
Designed for extension while providing
robust support for the base HTTP
protocol, HttpClient may be of
interest to anyone building HTTP-aware
client applications such as web
browsers, web service clients, or
systems that leverage or extend the
HTTP protocol for distributed
communication.
LDAP and authentication are separate issues from sending POSTs to web servers.
Th server side needs to do that authentication. Set it up either in your code or in the web server itself.
If your client is a Java application, you can create a POST using UrlConnection.
If your client is an HTML page or JSP, you need a form with a POST action.
Related
I have separate application for client side which is in ReactJs and NodeJS (Express server) and Web Services in Java application running in tomcat.
My query is which is better approach in terms of making web service call.
One is making direct web service call from ReactJS and get the data.
Other one is calling web service in Express server. Request from client browser will go to Express and Express will make all web services call.
I know one issue in making direct call to web service will be cross domain policy which can be handle by setting configuration in Java server.
Apart from it what should be better approach.
From my experience it ended up better using direct calls from UI application and avoiding intermediate server.
Reason for doing this directly is that our servers ended up with a lot of restrictions based on IP addresses, and all requests have been coming from intermediate server (nodeJS server), so DDOS protection of end server had to have some exceptions (our node server which could be on ACS with dynamic IP addresses so it might be hard to manage).
Also If you want to pass and track end users IP addresses, you need to manage headers on Node server (to be sure you are passing it as it was in original request).
It is way simpler to manage this kind of situation if calls are comming from React app and simply set up CORS on java server.
Also its way easier to debug it on UI app directly, so you will be watching response logs on one place only. Other way around you could end up debugging your node server and UI app.
Hope this helps a bit.
Best way IMO is to create a router in Node js specifically for all your Java webservices and act as a proxy.
Suppose if your url pattern is like http://domain/java-ws/api then all these requests will be routed to your Java service.
If you have an Apache server directing requests to your node JS then configure url pattern proxy using proxy module.
Browsers are blocking CORS requests for a reason. You may get away by setting things on your server.
Is it possible to prevent requests that are not using https from calling a get/post in code.
For example I am implementing a rest api with java and spring, and I would like to return a http status to the caller if they were not using https.
/api/getBlah using https would return the item, however using just http would not work and return the appropriate http status.
For an API server, I strongly encourage you to don't answer a redirect
If you do answer a redirect, if a developer make the mistake to use the http version of your API he will not see immediately that he used an insecure connexion
If you answer a "400 Bad Request", "401 Unauthorized" or a "405 Method Not Allowed" with a body explaining that only https is allowed, then the developer will immediately see the problem.
In short, answering a redirect http=>https in an API encourage bad practices.
There are a few different ways of handling this. Web Server Handling in my opinion, is the most common and makes the best use of the strengths of web servers and application serves.
Web Server Handling
As mentioned in the comments above, a common method of deploying Java web applications is to place a web server (such as apache or nginx) in front of a Java Application Server (tomcat, wildfly, jetty, etc.). The web server then proxies requests to the application server.
In a setup like this you can simply return a static response or redirect the user.. In this way, you don't need to return anything special from your own Java application. The web server does the lifting for you.
It should be noted (as in the answer from #Tom), that in the API use-case, an HTTP to HTTPS redirect is not best approach. This is more commonly
Application Server Separate Servlets
On the Java side, you could essentially create two separate web applications. The first would be configured to receive requests from the HTTP listener and would provide proper error messages or redirects. The other would be your main application and would be configured to only receive requests from the HTTPS listener.
Again responding with a static error would be best for an API.
Application Server Single Application
When a servlet handles requests, it will populate information in the ServletRequest, including information about if the requests was secure (used HTTPS). See the [ServletRequest documentation][2] and specifically the isSecure() method. You can inspect the ServletReuest within your application to determine the appropriate way of responding to the request.
Don't Answer
You can also simply configure your webserver/app server to not listen for HTTP requests. You'll miss the change to provide a sensible error to the user, but you'll achieve the affect of not allowing any requests over HTTP.
I want to develop a Java server that is able to send messages asynchronously to a client in form of a website with JavaScript. I know that one possibility is using WebSockets, but these are not supported in IE 9.
For transmitting messages from client to server I can use AJAX calls with maybe a RESTful Interface on the server side.
Does anyone have a solution for this?
This is not how webservers work, most of the time. HTTP Webservers are inherently a request-response architecture:
HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client.
That said, there are technologies that you can use to do this. Read here about Comet and Reverse AJAX:
Is there some way to PUSH data from web server to browser?
You better implement your Java server to act as a Websocket server when it's supported by the end user. For the users who does not support Websocket it should fall back to long-polling.
This behaviour will avoid unnecessary overheads due to long-polling communications whenever possible.
The good thing is you don't have to implement all these behavious from the scratch. You can readily embed and use a reliable implementation available open source.
One such implementation is CometD project. The CometD project was available for more than a decade and it has evolved to solve most of the issues.
If you are looking for commercial products, there are many available. One such would be lightstreamer (http://www.lightstreamer.com).
You need to use a design pattern like long polling since WebSockets is not available. Rather than build it yourself you could use a library like SignalR. SignalR is an ASP.NET library but there is a client for Java (https://github.com/SignalR/java-client)
For anyone who comes across this question more recently, the modern answer (as of early 2021) supported across all browsers (except IE, which even Microsoft has given up on in favour of Chromium-powered Edge) are server-sent events. A most elegant and standardised solution to providing a pub/sub model to web clients.
I have a java client that sends a message to the server .The server is a servlet deployed on jboss. My question is can the servlet send data back to the client as acknowledgment? is it possible in servlets?
From Java EE 5 tutorial chapter 4:
What Is a Servlet?
A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications accessed by means of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes.
Yes it is possible with servlets. Read the basics here.
Of course it's possible; a servlet that didn't have the ability to send data back to the client wouldn't be very useful.
There are many ways to do so but the most "raw" way is by writing to ServletResponse.getOutputStream(). The ServletResponse is passed to the service method of a Servlet implementation. Note that the data is of course going to be sent back as a valid HTTP response (identified using MIME, etc).
Ashwinm if you are looking for posting a result to a socket (on client) and not returing the result through mormal HTTP response.
Which I believe is not a servlet question then. You can anyway do anything in java. But have to look at normal "how to write to a socket" tutorial.
GenreicServlet might provide some extensibility or some solution.
EDIT
I read your commentes below later. Yes you need URLConnection in that case at the bare minimum.
An http servlet works on http request and can send back the http response. You can connect to it using URLConnection as described above.
If you don't want to get at this level (layer), you can work at with the packets directly (using sockets). Here you dont need a servlet actually. Here your server (a simple java application) will listen on a socket for any incoming connection and the client can connect to it.
I have the task of choosing an XMPP server/client solution for an internal web application. The goal is for employees to be able to utilize it via desktop client or the web application. The web client is mandatory.
The web application is written in PHP, but I don't necessarily need a PHP solution. Flash or Java are acceptable (Flash would be preferable since that's already required for another component of the application).
The web application requires javascript be enabled (and makes use of jQuery), so AJAX isn't out of the question either.
There are only two requirements that must be met:
The client must use a secure connection (HTTPS for AJAX, TLS for Flash/Java).
The client license must be commercial friendly. Free would be nice, but is not a requirement.
So far, I've found SparkWeb, which is LGPL licensed (hooray), but I have not been impressed by its live demo. I was unable to create an account on their server or connect to another XMPP server that I run, so I haven't even been able to see it in action.
I've also found Strophe, which looks good.
Another option is one of Tigase's client options. I'm not sure if the GPLv3 will like our usage though (I'll need to read it more carefully).
Any advice (or a shove in the right direction) would be appreciated.
About the licence :
GPL mandates you provide source code with the application.
So GPLv3 can fit.
Choosing a library, I see two possible options:
if you want a custom and great integration with your website code, building a webclient with StropheJS is possibly the best choice. But you'll need to code the client GUI. (more work)
If you want a good client but with limited interaction with the rest of the website, I'd recommande Tigase Messeger. It's written in GWT and has good support — especially if Tigase is the server you use.
Both of these libraries are pure javascript and use BOSH for communicating with the XMPP server.