I am making a website which involves lot of computing at the back end...I'm using Java Script at the front end and Java for the back end. Could there be any security problems because of Java Script or can I use any better front end instead of Java Script to make website better?
The biggest potential security problem with Javascript has nothing to do with Javascript (and also applies for "dumb" websites): If you think that the end user will only use your "official" client code, and as a result blindly trust the Javascript code with security-relevant information, then you have a security problem.
You need to validate all data on the server. The user can make his browser send whatever data he wants, whenever he wants. He does not even have to use a browser (could be a completely hacked-together tool).
You must not put "secret" data into the client code. Even if it is not directly visible in the browser, the resourceful user can see it.
Could there be any security problems because of JavaScript
Not intrinsically. You could introduce security problems by writing insecure code, but that is try of any language.
can I use any better front end instead of JavaScript to make website better?
Other options for client-side programming require browser plugins (such as Flash) or specific browsers (such as IE for VBScript).
You might not need any client side programming, and any JS you do write should be progressive and unobtrusive.
Related
I'm trying to decide whether to use GWT or manually-written JavaScript. If I use regular JavaScript, the Java app works like this:
The client accesses a URL, and the server executes a servlet.
The servlet queries a database and forwards the data to a JSP.
The JavaScript in the JSP displays the data in a table.
From what I've read, the process changes when you use GWT:
The client accesses a URL, and the server provides a page with GWT-generated JavaScript.
The generated JavaScript creates a table and uses GWT-RPC to tell a servlet to provide data.
The servlet queries a database and returns the data to the JavaScript, which displays the data in a table.
In the second process, the client accesses the server twice: once to access the URL and once to tell the servlet to provide data. I understand that the second part is performed asynchronously, but it still seems very inefficient. I'm sure I'm missing something fundamental, and I hope someone will set me straight.
OK, let look at this in terms of efficiency.
Yes for the simple case you describe, the client may have to wait slightly longer.
In terms of developing a useful site though, you most likely will be doing authentication and wanting to make ajax calls from the middle of your page. You too may want to do layout changes based on user input that are impractical and messy to do in a jsp page.
Manually written javascript used to run quite differently in different browsers too, and that was a nice thing about GWT compiling different versions for particular browsers. It may not be as true today but you should consider browser differences if you need to target more than one.
So my answer in terms of efficiency is that no GWT is not the most efficient for the simplest cases, but if you need to make a more complex web-application and want to avoid browser issues, then developing in Java is easier and simpler to maintain.
I actually am returning a .jsp page on my first call, and then the GWT javascript get bootstrapped from there (instead of using an html page). There isn't any real reason you couldn't include whatever data you wanted with the jsp page, except that if your requirement is so simple, keep it that way as for sure there will be some cost in bootstrapping the GWT code. In my case, I need to do authentication first, and then data than gets returned depends on their credentials, and then a load of ajax calls depending on what the information the user needs. Developing in javascript by hand would be a nightmare.
GWT compiler generated java script is cached on the client side so when you access application for the first time you will see that it takes some time as compared to plain java script. But if you try to access it again you will not see the performance issue in loading the page.
In both cases you are accessing the server twice. First request is to load the view and second request is to get the data from the server.
GWT is not suitable for simple application. It is mainly used for enterprise applications.
GWT compiler generated java script handles most of the browser intricacies which is hard to maintain in plain java script code.
The output HTML code is not complete, because the javascript in it is not executed.
Do I need to run the javascript somehow?
I want to get the content of a live-bidding website through java.
Rather than scraping the dynamic content, it would probably be more practical to figure out what the javascript is doing (e.g. what AJAX calls it is making) and code your application do the same thing.
You haven't mentioned which website you are talking about, but if they want you to do this kind of thing, it is likely that they will have developed a "web API" for people like you to use. And the flip-side is that they may not want people gaining an unfair advantage over other users by doing this kind of thing.
Either way, check the site's Terms of Service, etcetera ... or you might find yourself in legal trouble.
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.
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.
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.