I would like to execute a cross domain http request from a website. What are my options?
Javascript is out, because most browser don't allow cross domain calls. Generally the solution is to use a proxy, but that isn't an option for this project.
The other things I was thinking about would be to use Flash or maybe Java. Are there any other platforms that I could use?
You will have to stick with the proxy solution because flash and java have the same cross-domain restrictions as javascript. If this is something that is only for personal use, there is an option as I know with the flex builder and the debugger version of the falsh player which can make cross-domain requests.
Both Java and Flash support crossdomain.xml files, as documented on Oracle and Adobe sites respectively.
W3C is working on a standard that takes a different approach. When that gets implemented by which systems, I cannot predict.
If you have administrative access to the server you will be making a cross-domain request to, then you can make it serve a Flash cross-domain policy file that grants another server (or servers) cross-domain access. Then that other server needs to use Flash to make its cross-domain requests.
If you are looking for something to help get you started, check out the opensource Forge project. It exposes a cross-domain XmlHttpRequest API in JavaScript so you only have to write JavaScript code:
http://github.com/digitalbazaar/forge/blob/master/README
"Javascript is out, because most browser don't allow cross domain calls."
Unfortunately, Javascript is most definitely in. You just have to add a new script to the page with whatever src url you like. It's called Cross-Site Scripting (or XSS). IMO, the vulnerability it introduces renders moot all the other attempts by browsers to regulate a "same-origin" policy. They're just trying to patch a hole in a pair of pants that have already fallen down around your ankles.
Related
I am new to java web development.
Currently I'm learning technologies such as Servlets, Jsp, and Java Frameworks like Spring etc.
I was wondering that as an end user say for a java web-site without applets, would the user of the website be required to install java in his/her machine?
Because it seems that in the case of Servlet and Jsp all execution is done at the servers end and only the result is sent back to the user in html format.
Please correct me if I'm wrong.
As you suspect, Java is only run on the servers. It is the language that accepts an HTTP Request and processes it, issuing out an HTTP Response. As with most good coding practices, this means that the server program is returning a response that is, essentially, text. The implication here is that you can write the server in any sort of programming language, or set of languages, without the browser needing to know what or why.
Thus, the browser is agnostic to the languages you use on the server.
Java Applets are different; they are compiled Java code that is downloaded by the client and run inside a local JVM. For this to work, the client requires Java to be installed. Applets can be quite small - invisible even - and thus malicious sites can use them on unsuspecting browsers to do wonky things. For this reason people are concerned about Java security holes that would allow applets to do more than they should.
You are correct. The java is executing on the server. The user would only have to install java if the application served applets, which as you say, is not the case here.
No need to install java at end user(client).
Because HTML renderkit return html format.
But if his or her need to developed , java is need.
hi you need to install jdk if you want to develope any java project,the jdk itself contains jre( java runtime environment),,
you can prefer below link
http://www.journaldev.com/546/difference-between-jdk-jre-and-jvm-in-java
You do not need your client systems to have Java installed.
The news about disabling java in web browser was due to some security vulerabilities in the current release (which Oracle said they will fix in October release). But you do not have to worry about it since you do not have applets in your web site. The clients would need java jre installation if you have such plugins as applets
Http is a stateless and text based protocol. That means Http protocol is not able to remember its previous state and this can not hold any state of execution.Its a text based protocol so medium of exchange of information or data over this protocol is text.
Main issue with this protocol is that it can handle only one request at a time and send response to user in same manner. But in current time user requirements have changed dramatically. So Http can not handle so much requests at a time as well as cant managed to send multiple response. So Here Java EE and web servers comes into effects
Web-servers provide an environments where a web-applications(servlet,jsp,Java EE) can run,executes and send responses to the client. Web- servers perform task such as:
1: Handle a Http-requests and in the same way send the responses to that requests.
2: Since, Http protocol only understand text so , Web-server parse the request as a text,then process it and then transform that response again into a text and send it to the client server.
3: Provide an environment where web-applications ,request-response and other services can run flawlessly,dynamically and with strong security undergo.
4: And last but not the least, these web-servers are designed and developed in pure java and run it thread-model so you trust your application is in safe hand.
And applets runs in different way, client side at least need JRE to provide an environment to executes an applets. Applets are differs from web-technology.
I have a ajax frontend for my java backend, and to make things work with the crawls and HTML5 pushState I going to use HtmlUnit to process the javascript in every first request.
I can make a workaround with a Filter to not use HtmlUnit trying to reduce the server load.
Regardless of browser compatibility, which is best for the server?
After a lot of research and test I can tell that process heavy javascript applications on server side ins't I good idea, HtmlUnit is the best tool around and it doesn't do the job very well, so if your requirements are to support clients that doesn't support javascript, so go for PHP or some other server side script language or maybe JSF.
I my case, I have a Back-end in JAX-RS and I manage to support HTML5 pushState without process the javascript on server-side and assume that the client process javascript, HtmlUnit still in use for enable crawlability.
I have created a java app and I would like to be able to execute actions in this app by calling some custom urls (ex: myapp://do_this)
I have already searched for this, and I have found some information about handling such urls in java (URLStreamHandler).
The only part I'm missing, is how to tell the OS to redirect the "myapp://" protocol to my application.
More and more apps are defining their own protocol and I was wondering whether it was possible to create such kind of things in Java.
Thanks
The protocol in URLStreamHandler will be used inside of the jvm. Typical usage is something like res://... for resources. The OS and the browsers have their own sets of protocols (ftp, mailto).
You could probably extend Firefox with a plugin to handle your protocol.
But then you have to send that to your app, running as a small "web" server.
Forget for a moment URLStreamHandler.
Embed the Jetty web server in your app, say on port 8765, and write a servlet to handle your URLs. Then you can in your browser type "http://localhost:8765/do_this". Should suffice.
To add a new protocol, one needs to implement an XPCOM component. Since XPCOM allows programming languages to talk to eachother, XPCOM components can be implemented in C++ or JavaScript currently in Mozilla.
http://www.nexgenmedia.net/docs/protocol/ will help you to understand more.
i think this is what you want.
As others have said, getting browsers to understand a new protocol name is browser (and OS) specific - you can't do it from the server.
However, would Java Web Start ( http://download.oracle.com/javase/tutorial/deployment/webstart/ ) fit your requirements? Most browsers are already set up to handle JWS applications correctly.
I need implement a server that is publicly accessible from the internet. The server has a very simple mission:
Accept form POSTs from users over HTTPS (the actual HTML form is on a different site)
Rewrite the form post as JSON
Send it to an internal server over separate HTTPS connection, with multi server fail-over
Wait for a reply in JSON, containing either success or a error reason
Return a '303' redirection from either to a success URI or a failure URI, putting the error reason as a query parameter
The load this server is normally subjected to is minimal, but since there are no access restrictions, the server can obviously be attacked by DOS etc.
However, the real issue here is that security is absolutely paramount for the server - the server is involved in payment transactions with a large enough volume to make it a desirable target for cracking. The server is behind an IPS, but is otherwise directly connected to the internet and will terminate the HTTPS connections from end-user browsers directly without any intervening reverse proxies or SSL accelerators or such.
So, my question is, which Java web server would be the safest choice for such a purpose?
Or, alternatively, if you really think such requests should not directly be received by Java, but by lighttpd or something else, you may propose something else. But only if it can fulfill the requirements given above.
A really nice answer would touch on these issues:
Relevant security of OpenSSL vs. Java crypto vs. alternatives (all have had vulnerabilities)
Relevant security of Java VM features (such as recent XML parsing vulnerability)
Relevant security of web server's HTTP header parsing (almost all seem to have had vulnerabilities there)
Relevant security of optional compression (zlib has had vulnerabilities and mod_deflate has had separate vulnerabilities on top of that)
I'd argue that your main concern should be following best security practices and keeping your software up to date than specifically which software you choose. It's just about impossible to predict future vulnerabilities. And software with a lot of past vulnerabilities doesn't necessarily mean it was less secure, likely it was targeted more often and thus fixed more often. In that regard you want software that is regularly updated and you have an easy way to routinely get those updates.
I'd suggest Tomcat and follow the steps from Improving Apache Tomcat Security. Tomcat has the benefit of being common and open source, so it gets a lot of attention and quick fixes. Many attacks are against things you don't even need, so disable everything you can. Configure your web.xml to only accept URL paths you expect and give an error for everything else.
It doesn't sound like you need Apache HTTPD in front of the web container. It's probably best then to reduce the number of attack vectors and have web requests go directly to the web container. It's not possible to know which of HTTPD or Java are going to have more vulnerabilities discovered for SSL and gzip. Yet if you use only Java then you're at least not open to the rest of what might be found for HTTPD, versus a limited set of native implementation concerns for Java.
Make sure Java and your web container are kept up to date. Network and OS hardening should be researched too, if they haven't been. You might also want to look into daily scanning for web vulnerabilities to stay on top of new threats.
If you need something simple and single-purpose, I would give a try to Grizzly - less code, less bugs. It has some SSLConfig class to setup HTTPS, altough I have not used it.
Most servers are capable of that. Tomcat is an obvious choice. Tomcat behind Apache is also common. If using JavaEE - any application server would work.
Using any language (php, java, ruby, python), what's the best way to login to a website programmatically from the server? (for example, login to amazon, jetblue, etc. )
Are there are some frameworks to make this easier?
You could use Ruby or Python with Mechanize (ruby implementation, python implementation).
Mechanize is basically a browser and you can have it programmatically submit forms or send the appropriate HTTP request/response data to maintain a "fake" session.
There are a number of these kinds of tools, I've recently had some good experiences using python+mechanize.
Unfortunately, this has to be configured on a per-site basis. Each site uses its own login forms / urls, and potentially uses a different-named cookie (or whatever) to track your login session.