Before I jump both feet in and waste my time learning something that I can't use for my needs, I have to ask:
Can I make a http connection to another website from within a java applet or a flash file?
Say I have a java applet that wants to load results from google. Will the JVM give me access to such a call? What about Flash? I've read about URLLoader but am confused with the this:
" * Data loading is not allowed if the calling file is in the local-with-file-system sandbox and the target resource is from a network sandbox.
* Data loading is also not allowed if the calling file is from a network sandbox and the target resource is local."
Anyway if it isn't possible, will it fail on the user silently or will it ask for permission?
Thanks a lot.
Of course you can do that in Java, and also flash. However some browsers and environments may restrict by forcing security levels.
The warnings you found were related to local<->remote. For web applications which is hosted on network, you can usually access other network resources. (well, some may restrict you for "other" domains - you'll need to check the security models)
But modern technology usually suggest you to do that with the combination of JavaScript. Google for "Ajax" and search for some frameworks that best fits your requirement - that would save a lot of time.
Yes, but the problem is that for security reasons, many browsers only allow the application to connect to the domain from which the application came from.
so for example, if I go to website A and my app is trying to make an access to website B, it could sometimes be blocked (e.g., to avoid spamming, attacks, etc.). A work-around, if you control website A, is to create a "pass-through" script on website A that will send the request to B.
Can I make a http connection to another website from within a java applet or a flash file?
From Flash, yes. You do need to read up on the Flash Security Model to be sure what you can and what you cannot ask. Most of the time this is to stop unauthorized access and/or XSS or similar attacks. Flex (a related technology), for example, does not give you access to your disk, whereas AIR does. Take your pick.
As for applets, you'll have to wait for someone else to explain it to you. But AFAIK, it also has a security model to pose the least threat to its users.
Java, JavaScript, Flash, etc., implement some form of "same origin" policy which only allows untrusted code to read from the site it was downloaded from. One way around this, supported to some extent by recent versions of Flash and Java since 6u10 is crossdomain.xml (Google it). This allows sites to permit access via code downloaded by other sites. Note, this requires the site you want to access to grant you permission to do so.
Not with ease. By definitions Java sandbox won't let your applet call other than the origin it came from. You will have to sign your applet properly. Then users will either trust your applet and let it call elsewhere, or deny it - it's up to user. You can self-sign your applet, but I would personally never allow such thingy on my computer. It's good for testing and stuff like that. So you'd probably need to buy a certificate from reputable source. Same to the Flash, I believe the idea is identical.
Related
We need to read a file via http(s) that can require authentication via different protocols. I think we need to handle:
Basic
Digest
Windows (I think this is the same as NTLM?)
SharePoint (via FBA)
Claims Based authentication for OData access of SharePoint & MS Dynamics.
Numerous systems that provide token(s) on login that must be placed in the header of each read.
Is there a single way to do this in Java 6 and/or an Apache library that covers all these cases? And if not, I know how to do Basic, Digest, & header injections, but is there anything showing how to do this for Windows, SharePoint FBA, & CBA?
And is there any commonly used protocol not in my list above? This is read only so no need for WEBDAV.
As to why such an all-encompassing need, this is for a commercial library we ship. I have no idea what our customers will face and so I want to try and cover any possibility.
thanks - dave
Here is an 'answer', sort of.
Before addressing the question as you wrote it, I want to throw a challenge back at you: Why does your library need to take responsibility for opening remote resources? Most library APIs are written to accept input as InputStream or Path, and leave it to the application that calls them to work out how to get access (in the former case) to the particular resource of interest, whether local, remote, or invented on the fly.
Further, your restriction to Java 1.6, now long unsupported and mostly considered obsolete, will severely constrain your ability to find open source assistance in offering broader functionality that 'you can be called with an InputStream'.
However, having written that, there is a big difference between resources available via HTTP/HTTPS and resources available via other protocols. Java intrinsically supports HTTP, and libraries such as hc.apache.org provide broad assistance with some of the more annoying details (though, again, there hasn't been a 1.6 compatible release of that for some time).
If you feel the need to support protocols beyond HTTP, you are in a much more difficult landscape. In the mostly-linux ecosystem, the usual next thing is SSH protocol, for which there are good open source alternatives. For more-or-less proprietary protocols such as CIFS (Windows shares), let alone the really Microsoft-specific items, Google will give you all the answers there are, which is why questions that 'ask for an off-site resource or library' are officially off-topic here. You're perhaps better off requiring your customers to enable HTTP access to the resources.
We have two applications. One application in .asp and second application in java.
we want to build interface for universal authentication, so that one can access the other application once signed into one application.
Both applications are using SQL database, but one is written in .ASP
hosted on Windows server while the other is in JAVA hosted on a Linux
server. The applications are currently resided on two different
servers.
requirements:
1)The end user are most likely to access the applications through
.ASP first, then reach the 2nd application more like "back office"
management system.
2)he JAVA application currently works well with IE web browser, but
not very smooth with other browsers such as Firefox. Would like to
make the application to be more compatible with other browsers.
Please help me, its very important to me. Thanks in advance!
You haven't really asked a very clear question, but a few ideas:
If you had a web service which both platforms could talk to, then the two user interfaces could be reasonably shallow shims over the single code-base
I assume the Java application is actually still a web application, e.g. with servlets? Cross-browser portability has relatively little to do with the technology powering it... it's all in the HTML and JavaScript delivered to the browser. If you have a specific question about how to make some aspect of a web application work well in multiple browsers, you should give details of that.
Finally - do you really need two applications? Even with something like a common web service, you're likely to end up having to write several of the presentation aspects twice, doing very similar things. Is there any reason for not just settling on one platform and making a single application which covers all the requirements currently satisfied by the two applications?
You'll probably want to have a look at Single Sign-On solutions, of which there are quite a few out there in the market. A lot depends on what flexibility & control you have over the applications in order to make changes to integrate such a solution. It also matters as to whether these systems are on a public internet or just have internal clients.
A popular Federated SSO is Shibboleth though I doubt you'd want to put in such a solution for only two servers. It's features might help you clarify what you need from such a product though.
In a place I used to work, for purely internal clients, we just used Windows Domain authentication to allow transparent access to both Windows/ASP and J2EE/Servlet applications. It used JCIFS/NTLM filters for the Java authentication piece so there was never a need to sign onto an application explicitly, the users' login credentials were exchanged between their PCs and the web application "under the hood" and their AD group was membership retrieved to inform their J2EE roles (with the application then controlling access to the database) in much the same way an NTLM authenticated ASP page was handled.
Is it sufficient to secure a Java web application with the rights of the user that is running the application server process or is it reasonable also to use SecurityManager with a suitable policy file?
I have used to do the former and not the latter, but some customers would like us to also use SecurityManager that would explicitly give permissions to every third-party component to be sure there isn't any evil code lurking there.
I've seen some Servlet containers, like Resin to propose not using SecurityManager to slow things up. Any thoughts?
While I hate to ever recommend not using a security feature, it's my opinion that a SecurityManager is more intended to manage situations where untrusted or third-party code is executing in the JVM. Think applets, or a hosted, shared app server scenario. If you have complete control over the app server and are not running anybody else's code, I think it's redundant. Enable the SecurityManager does have significant performance impact in my experience.
There is no simple yes/no answer to your question, because it really depends: what do you want to secure, and what do you want to secure it from?
For example, I've used SecurityManager to implement IP filtering and allow only whitelisted IP addresses to connect to my application. If you just want to disallow access to disk files, maybe running application as user with lesser privileges is better solution.
If you don't trust third party plugins at all, remember that once you allow execution of plugin code, that plugin can crash your application if it wants to even if you use SecurityManager. If your application loads plugins, maybe whitelisting plugin and checking the list before loading plugin is better solution.
If you decide to use it, you will take a performance hit (since JVM will do more checks), but how fast it will run really depends on your code/configuration that will do the checks. My IP whitelist was pretty fast since it included only single list lookup; if your checks include invoking remote web service and accessing database you can slow things down a lot, but on the other hand, even that should not matter if you have enough hardware and few concurrent users (in other words, if you can afford it).
Correctly configurin Security Manager in java can be hard. For instance, if you do not restrict the security manager itself, one can bypass all security just by setting the Security Manager to null.
Using a security manager only makes sense if your JVM will run untrusted code, otherwise it is a pain to set up, because you'll have to know beforehand what permissions you should set for each feature (ex: RMI, sockets, I/O) and for each client.
I'm creating a Rails application and on it, there should be a Java Applet.
My question and problem is that the applet must be tightly integrated with the Rails parts. I must be able to get a list of all users, update an image, etc... And there's a surprisingly small amount of information available on the Internet of how to use applets with Rails. So please give me some hints. What is the best way to do it?
Send parameters to the applet?
Use Rails REST interface from the applet?
Use JRuby somehow?
Other....?
Thanks!
Can you provide more details? In the meantime, here's my take on your questions:
Send parameters to the applet?
Your rails app will be able to serve the applet, but once served I don think you'll be able to send messages to it (however you will be able to respond to messages from it, which is perhaps what your asking).
Use Rails REST interface from the applet?
You've kind of answered that one yourself. REST is an interface design and therefore can be accessed from anything that can issue a HTTP request. The trick is to correctly construct the URL so rails knows what you want to do. There's good info on configuring rails routes (REST and non-REST) here http://guides.rubyonrails.org/routing.html
Use JRuby somehow?
You could use jruby for this, but you dont need to. Your server (rails) and your client (browser/applet) talk to eachother via http and so don't need to be the same language or run on the same VM.
Hope that help....
I think the reason you probably haven't found anything specific about Applets and Rails is that they function a bit at different levels and aren't really dependent on one another. It looks like Rob was trying to clarify a few things, so I'll take it another step just to be sure we are all on the same page.
The job of Rails is to generate and serve up HTML/XML/Javascript/images via a web server to the user's web browser for rendering. Part of that HTML will be an APPLET (or possibly OBJECT) tag, which instructs the browser to load the applet. Usually, this instructs the browser to invoke the Java Plug-in and lets it handle loading the applet. Once loaded and running, however, even though the applet is displayed on the current web page in the browser (or maybe in another window even), it really isn't terribly aware of the web page it is sitting in. For the most part, applets don't care about the browser or the page they are "part of". So if an applet needs more information, or needs to ask for data, it usually will just send an HTTP request to the server it came from. It would then parse the data and update itself.
I am assuming what you probably need is for something to be clicked or entered into the applet, and that data be used to update the web page that Rails is serving to the browser. With an applet, you pretty much have 2 options:
Use the web server application to share state information
Use the Java-to-Javascript communication using JSObject as indicated at http://java.sun.com/products/plugin/1.3/docs/jsobject.html
Honestly, option number 2 comes with so many caveats, that I would never use it unless you had complete control over browser and Java versions on all potential users' systems. Even then, I'd be concerned of an update to something breaking it.
Basically, option number 1 leaves you with the Applet and the Javascript/HTML polling the web server (Rails) periodically to see if there are any updates or requests that they need to respond to for data exchange. If the applet is updated by the user, it sends a message to the web server via a URL request/post and the next query (probably via an AJAX-like call) by the web page will see the new data and the web page will be updated with it.
I hope that helps.
Two really great answers. I appreciate them a lot, thanks!
Reading your posts made me realize that the best choice is to use HTTP-requests to Rails REST interface. However, I see some downsides with this approach. But I don't see any better solution to it. One feature the applet should have, is to be able to browse and search in all products, which can be quite many. Sending a HTTP-request for each search will be expensive. Maybe I could solve this by loading all products when the applet starts. Then the browsing and searching would be fast. Or maybe do some nice caching. So once they are found, I don't fetch them again.
About not finding lots of information about this on the net. I see your point monceaux. But... I still think that there should be more. I mean, in my situation I would really like a Rails specific library that helped me send requests to correct urls. To bad Java is not that dynamic though. Kind of hard to do some stuff automatically, like in Ruby and Rails. Maybe I'll write a small library for this. I mean, I must write it anyway. So why not make a library of it? Some people might have use of it.
Why is it not advisable to use JavaScript in JSP? One rationale that I can think of is turning off the feature in browser would stop the code from executing. Is there any other reason behind this?
Afaik, there is no problem in using javascript in jsp, and many sites do use it. Especially if your site is a web app, you will have to use both side by side. They are completely independent. You just have to make sure that what you are using each for is appropriate.
As for the part about turning off javascript in a browser making the site unusable, it is true whenever you use javascript, with or without jsp.
I know this is a very old question but I thought I would pipe in anyways. I think you should use javascript in this current time period as it allows for a very rich user experience and with js libraries like jQuery (my personal favorite), prototype and mootools it has become very easy to integrate javascript into your application with little effort.
If you design your application right, you can add javascript that enriches the user's experience (and can make it easier for them to use your site/application) without additional server overhead and very little effort.
How ever - your site should not rely on the javascript for function as the user's browser may not support it.
Javascript should be unobtrusive and provide a richer experience to those user's who support it.
Here is a good article about UI and upgrading gracefully instead of designing for the failure of the user's browser. http://realtech.burningbird.net/javascript/accessibility/gracefully-upgrading
He's got to mean "don't use java scriptlets", which is the stuff between <% %>.
The biggest reason has got to be maintainability and debugging; scriptlets make everything make both very difficult.
On the other hand, if you implement taglibs, you can extract any logic to a real java class, which is easily debugged, and you will still be able to open things up in a visual xml/html editor, since taglibs are a valid xml structure.
Now, it is a bad idea to do validation on the client side (in javascript). Users can disable javascript or even access a url directly to get around validation, which opens you up to exploits.
If you have many clients, then it may be a good idea to put calculations on the clients with JavaScript. If you do everything on the server, you are just going to waste the many processing powers provided by the client's browsers, and the speed advantage of Java would be for naught if too many clients make the server busy. (Thanks to #Subtenante in the comments for pointing this out!).
But on the other side, Java running on the server is faster than JavaScript on the client, and it won't suffer from redundant code on the client, for testing which browser the client runs.
JavaScript has its uses as trex pointed out, though. Since it runs on the client, it can for example validate form fields before sending it to the server.
JSP is a server side technology. That is - Server parses/compiles all the information and then sends it to the client (i.e. your browser). And then..
If received data contains ANY javascript then browser interprets it in its own javascript VM and server is long forgotten by then since HTTP is stateless protocol.
Considering "not recommending JS in web" I wouldn't bother about it. Most of the sites use JS extensively thus turning it off on the client side would render them mostly useless.