I'm working on a project where I have a simple ip camera that has an mjpg stream with an internal address and a web server. I would like to serve the camera's feed through my servlet so that the camera does not require port forwarding for each installation. My ideal situation would be that the user would only enter the URL for the mjpg's location (located on their network) and the servlet would handle the rest.
I'm pretty clueless on how to begin implementing this or if it's even possible as I'm not actually creating the mjpg stream myself, I'm using the one that already exists. Is there a way to do this without making an obscene amount of requests to my web server?
An additional thorn in my side is that I'm restricted to libraries that would work in J2ME.
In a servlet, you can simply inspect the HttpRequestObject for the URL, method, and probably accept header, then create an HttpURLConnection with the ip address of the appropriate camera, make the connection. When you get a response back from the camera, copy the appropriate entries from the response and set them in the ServletResponse object, and then get the camera response input stream and the output stream for the client's request and copy the bytes from one stream to another, and close everything up when you're done.
If you can deploy something like Jersey, the JAX-RS reference implementation, this would be even easier.
Ok. So you basically want to proxy several cameras to be connected to via a single servlet?
It shouldn't be too hard. You just need to open up a socket connection to the requested URL in your servlet.
Assuming you're using HTTP, if you had a request for "http://myservlet/servlet?url=http://camera_url_here", you should just be able to open up a connection to the camera URL and write the bytes received to the HttpServletResponse's Outputstream. You might want to stick your socket connections in a Map, so that you don't needlessly connect to the same camera twice. Don't forget to copy/set the correct MIME types in the HttpServletResponse object.
Have you looked at http://www.videolan.org/vlc/streaming.html ? I'm pretty sure it can already do this.
Related
When I say drop connection I mean actually closing the socket without reading any more bytes. I am trying to prevent a DoS attack where the attacker is trying to make a lot of HTTP requests that upload very very large files. For my purpose, I will consider any client trying to upload file larger than a pre-configured amount as attacker, and I would like to terminate the connection ASAP without reading even single more byte (I would like to send a HTTP 413 back to client if possible, but I don't care if the client receive the response or not, I just don't want any more byte from the client).
I have a app that runs within Jetty and from what I observed even if I throw exception, Jetty itself will still consume all the request body (and drop them) as part of the HTTP request life cycle.
So how do you guy do that? Through Jetty itself or through some kind of reverse proxy?
I know about maxFormContentSize and Apache File Upload, but they don't really do what I am looking for.
I am trying to block certain websites using a web application. So, when a I type a url suppose "http://www.google.com" it should first check whether google is blocked by my application or not. If not open the website otherwise reject the browser request to open it. I am unable to find a way to capture all HTTP request from browser so that I can process it.
I Know proxies are the most suitable option but is there any alternative solution to this. After some searching I found a library - jpcap (a network packet capture library) and I was wondering if this could help me or not?
What you are trying to create is a proxy-server.
You have to configure the browser to go through the proxy, then you can deny websites, reroute them etc.
There are many proxies already there (open source and commercial) that offer what you want.
For example: Squid http://www.squid-cache.org/
See Wikipedia description of a proxy here: https://en.wikipedia.org/wiki/Proxy_server
Many firewall products offer the service of a transparent proxy, redirecting all http/https traffic going through the firewall into a proxy server. It seems, you have a direct connection but your packages are really filtered. Aka transparent proxy.
If your assignment does not allow this context, you need to check the assignment again, if you really got the scope of filtering right.
You cannot take over the browser's ip communication from a servlet or servlet filter. Using a (servlet) filter, you can only filter requests directed to your application. One step above, using an application server valve (Tomcat uses this term, others may use a different one), you can only filter requests directed at that server. One step above (or below) your application server is the physical server and the network it is running in.
If your client does not share the same network as your server, you can't even apply transparent proxy to it. Since browsers are running on the client computer, most clients in the world do not share the same network zone as the server.
It just does not work as you expect it.
I tried using Muffin's web proxy to record the url's that were hit in the browser.
I am able to track the internet request like google.com,stackoverflow etc.,
But, was unable to track the intranet request like the one which does not need internet. I am not sure how intranet works because those request for the url were not being tracked.
Is there a way to track those request as well(intranet urls).
1) I am able to track the weburls because i am redirecting all the request to the socket i had created in java.But setting it up as a proxy in the settings.
2) Usually intranet sites do not rely on the proxy servers. it will directly communicate though dns server.How to make those request also to go through my socket ?
Note I am trying to achieve it using JAVA sockets.
Use a windows application called FIDDLER.... It can track all type of inbound and outbound connections...
I currently have an TCP Java socket communication implementation in which I have a server that is listening to a port (let's say port 5478). Then I need an Android client to remotely connect to the Java server and send a SQL query, than will then be executed on the server side database and then I want to send a list of results back to the Android client (already implemented with a custom Java class named Result that implements Serializable). I do this by sending an ArrayList of Result to the Android client. The Java server is always listening to the port and supports multiple clients trough multiple Threads. How can I migrate this implementation to a more secure platform and what is the best way to do it? I don't need to respect HTTP protocol to afford this communication. Is Tomcat the best solution?
Thanks
I would use Servlet3.0 as part of tomcat.
Then from android you just have to send http requests to the server using a URL and the servlet can database them. You can also serialize the data as well if you need to.
I hope that answers your question.
~ Dan
//EDIT:
Once you have set up eclipse and tomcat, you can start writing servlets. First - you have to configure the server to use servlets for certain addresses, for example localhost:8080/myServlet - that means that anything you send to local host triggers the servlet. The code for your first servelet looks like this:
public class ExampServlet extends HttpServlet {
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
Your doPost method is what gets called when you perform a http post request on the address the servlet is listening on. Then, all you have to do it put some code in to read the request to get the data out of the message body. Basically you read your request object that gets passed in, and you write to your response object to send the response back to the client. There are plenty of guides out there. I followed something like this to get started:
http://www.coreservlets.com/Apache-Tomcat-Tutorial/tomcat-7-with-eclipse.html
Hope that helps :)
~ Dan
Tomcat is an Servlet container + webserver. If you plan to move to tomcat then you are implicitly moving to http. And yes, if you want a secure communication .. you can create a soap based webservice(apache axis) and host it on https.
I'm not sure how mutch additional security tomcat is able to provide for your application. Two tings come to mind:
Enforcing authentication and some access rules. This is not too hart to implement and heavily depends on the rule quality. However it may help f you use it. It's often replaced by own imlpementations. However, to get securty you need encryption i.e. https. Or it's possible to steel the session and gain the rights bound to it.
Request to file mapping. This in fact somewhat more complicated. You shouldn't code this on your own. It's more complicated than it looks at first sight.
However, one of the biggest security wholes ever is directly executing code you got from somewhere. For example SQL statements. Ok it's secure as long as your databse rights are set perfectly...
Developing a securly encrypted protocol is not simple either.
However, the major win on switching to tomcat (or whatever) might be scaleability for free. And I think implementing servlets is much simpler than programming against sockets. And there are many great to tools fo working with http(s) though ven it might be more complicated than yours, it's pretty simple to deal with.
Unfortunately I can't answer our question. I don't know what's the best solution is. But I think there's at least some potential for wins.
This problem relates to the Restlet framework and Java
When a client wants to discover the resources available on a server - they must send an HTTP request with OPTIONS as the request type. This is fine I guess for non human readable clients - i.e. in code rather than a browser.
The problem I see here is - browsers (human readable) using GET, will NOT be able to quickly discover the resources available to them and find out some extra help documentation etc - because they do not use OPTIONS as a request type.
Is there a way to make a browser send an OPTIONS/GET request so the server can fire back formatted XML to the client (as this is what happens in Restlet - i.e. the server response is to send all information back as XML), and display this in the browser?
Or have I got my thinking all wrong - i.e. the point of OPTIONS is that is meant to be used inside a client's code and not meant to be read via a browser.
Use the TunnelService (which by default is already enabled) and simply add the method=OPTIONS query parameter to your URL.
(The Restlet FAQ Q19 is a similar question.)
I think OPTIONS is not designed to be 'user-visible'.
How would you dispatch an OPTIONS request from the browser ? (note that the form element only allows GET and POST).
You could send it using XmlHttpRequest and then get back XML in your Javascript callback and render it appropriately. But I'm not convinced this is something that your user should really know about!