I am planning to allow users of my JavaFX program to select a custom CSS stylesheet, so that they can fully customize their UI layout and design.
I am wondering whether this is a safe idea as I am aware this can be dangerous for certain programs as it allows for people to inject code, though I can't seem to find any information on the possibility of using CSS for anything other than defining styles in JavaFX.
This is not a topic you need be concerned about.
Only read on if you are still concerned...
Ah, so there is no chance a user could use a stylesheet to somehow manipulate the program maliciously?
Well I would not say no chance. Software is complex and exploits can be unusual and unexpected.
But, the chance that it would happen and cause enough harm to the users of your app that it was worth investments by yourself in potential countermeasures is IMO, infinitesimal.
Your, and other’s, effort is best spent elsewhere. Use secure servers and packaging, use up to date frameworks and libraries, patch or redeploy for known exploits, etc.
A JavaFX app where you supply all the code and the app is installed as a package on a client machine is an inherently different attack surface than a web browser sourcing from many network locations that you do not control.
There is no server side cross site code injection without cross site servers. So trying to apply a website css attack (which is not normal by the way, most site attacks are scripting, phishing, server infected malware, etc) to a JavaFX client isn’t going to work.
If you are still concerned then do your own further research into the subject.
Related
I have an (unsigned) applet that let you draw a logic circuit and test it on-screen (a bit like Electronics Workbench), and it then serializes the circuit (the internal form, not the visual representations) and sends it to the server where a bunch of automated tests are run and a performance report is produced. This is a small but crucial part of a much larger web app.
However, the latest Java plug-in now says this:
Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk.
Now, self-signing it will still apparently work (for now), but then the code runs OUTSIDE the sandbox, which strikes me as a stupid way to do things, even though my code is of course completely bug-free! (Can I interest you in buying a bridge?) Reading further on the Oracle website I see this:
The platform will not deny the execution of Java applications... Future update releases may include additional changes to restrict unsafe behaviors like unsigned and self-signed applications."
(Which sounds like it means "Future updates will deny the execution of Java applications" -- unless you pay money to Thwaite or Verisign on a regular basis AND expose users to code running outside a sandbox.)
They also say
"Even the smallest changes in user experience are sometimes troublesome".
(No kidding.)
"We have considered how changes affect user experience. Given the current climate around Java security in the browser, code signing is a valuable security control for protecting Java users."
Well, I don't see how I can continue using Java under these circumstances. The goalposts have been moved (again), and now I'm looking for a different football team... or more precisely, I'm looking for an alternative technology that will let me continue to do what I do now: drag & drop circuit elements, create connections by dragging between input and outputs or other connections, and finally take the internal form of the diagram and squirt it to the server in a form which can be decoded and exercised, preferably by exactly the same code that created the diagram to avoid versioning headaches. And something which is safe, which can't trash the local filesystem or whatever just because I've signed it.
Can anyone suggest where I should be looking next, now that Oracle has made my life a nightmare?
(Which sounds like it means "Future updates will deny the execution of Java applications" -- unless you pay money to Thwaite or Verisign on a regular basis AND expose users to code running outside a sandbox.)
A signed applet launched using JNLP can still be sand-boxed.
But if you really wish to avoid it..
I think what you described can be provided using JavaScript for the logic and and an HTML 5 canvas for the rendering.
I would avoid Flash, since it is also susceptible to security bugs. It would be like digging yourself a brand new hole to get trapped in.
I can't comment on what you found about applets, since I never wrote one.
If you want to move away from them, maybe your only option (while staying with Java) is go for web applcations, where the code is most on server-side and you interact with your software directly in your browser. On the client-side javascript (and js-related libraries like JQuery) is used, though I can't elaborate about it more since I'm don't know the Java EE stack very well yet.
I'm not sure if you can get 100% the same user experience as you currently have in your applet, above all for an electronics application. But it may offer the highest code-reuse of most of your Java classes.
I've used Vaadin, it's a framework that moves almost all your coding to the server-side (you only need to code the client side if you want to create addons). I've heard about Zk too, but I've never used it, so I can't say anything about it.
You can still run unsigned java applets in your web pages if you block your Java plugin in the browser to the version SE 7 U11 (jre-7u11-windows-i586.exe) Of course you will have to block automatic Java update with "C:\Program Files (x86)\Java\jre7\bin\javacpl.exe"
I hop you can survive for a while this way, before you find an alternative to JAva applet.
In HTML5 the tag to call an apllet is now object and the syntax is a bit different:
<object codetype="application/java"
classid="yourApplet.class"
codebase="http://www.yourserver ..."
archive="YourJarFile.jar"
width="x" height="y">
<param name="paramName1" value="paramValue1"/>
<param name="paramNamei" value="paramValuei"/>
</object>
I'm a pretty skilled java programmer that has dabbled in web development but I find that I'm much better at doing desktop based stuff than I am at anything related to web development. I've been trying to find an easy way of porting some of my desktop apps to run in browser but can't seem to find anything. I guess what I'm looking for is something similar to an applet but they a largely unsupported and get more buggy by the day. Is there anything similar that would allow me to keep my desktop style mindset and still run in browser or should I just break down and rewrite the whole thing in rails or another common web platform.
Java WebStart has been mentioned by others - It's a technology that aids redistribution of Java applications that then have the full rights of desktop applications, but they also have auto-update support built in. It's basically a launcher that fetches a JAR from the internet and runs it as a desktop application. These don't run within the browser.
Applets are an old technology that can be embedded directly into the web-page. They are not buggy, but they have several security restrictions. Also, the support is steadily declining because of the amount of critical bugs found in the technology. Desktop users that want applet support typically don't have trouble ensuring it, however. Currently, both the Chrome and the Java platform itself issue a warning before an applet is allowed to run - and that assumes the Java Runtime Environment is already installed.
Google Web Toolkit is a framework that allows creating single-page applications in Java, which are then compiled to Javascript. GWT handles multiple things behind the scenes, including server-client communication, localisation and internationalisation, and its own layout engine.
When translating an existing application to GWT, you need to:
separate the code into a part that runs on the client and a part that runs on the server. The server does not have direct access to the user, and the client does not have direct access to the database. If your application does not use centralised storage, it probably can run entirely within the web browser. Since client-server communication happens over the internet, you should reduce it to the minimum.
translate the front-end to GWT widgets. Forget Swing or AWT - they are impossible to compile efficiently to Javascript.
remove dependency on other Java classes that the GWT does not know how to translate into Javascript in the client part of the application. A large part of java.util. is supported but none of javax. (as of Jan 2014). The GWT site hosts the list of supported Java classes. Also, Javascript's regexes are less powerful than those of Java. Lookbehinds, in particular, are not supported. The server-side is a full-blown Java environment, but remember - you want to reduce the server-client communication to the minimum.
But, the most common strategy is to code the client side directly in Javascript.
Javascript is a language very similar in syntax to C/C++ and Java. It uses curly braces to denote blocks of code, and it uses semicolons to separate statements (though Javascript features automatic semicolon insertion, sometimes it understands two lines as a single statement if the first line is not terminated by a semicolon. Its data types include numbers (double-precision floating point), strings, booleans, two types of null, plain objects (which are basically hash-maps [string -> x]), arrays (untyped and dynamically extensible), regexes and functions (named or anonymous), all of which have their own literal syntax.
When coding in Javascript, your mindset should be:
Javascript is single-threaded and event-driven. You don't have to worry about concurrency issues, but you cannot say "now wait for x" either. Since Your Java code should be event-driven as well, this should not be an issue.
Lots of things in Javascript are asynchronous. Want to know something from the user? You should paint a dialog, and attach event handlers to its components. Want to get the user's GPS position? Ask for permission, passing it an event handler for when the user decides if the permission should be granted, from which you ask for the position, which also takes an event handler as an argument. Talking to the server? Asynchronous. Do you want to display something before doing a long calculation? You have to actually wait a little before you start computing. Ecmascript 6 improves the syntax a lot, but it's not yet supported in modern browsers.
Browsers only let you do so much. Disk access? Only to a file or folder the user explicitly points to. Clipboard access? The only reliable way is copy/paste into a textbox. Talking to a foreign webserver? Only if that webserver explicitly lets you (and lot of them don't even know how to). Of course, "foreign" includes a different sub-domain, different port number or a different protocol (http:// or https://). Desktop notifications? Geolocation? Ask for permissions first. Java applets have comparable security restrictions, and for the very same reason.
In Java, everything is a class. In Javascript, you can enjoy bare functions without any class. A typical event handler is just an anonymous function that you pass as an argument to a library function. Also, you can have anonymous objects using a very conscise syntax. This makes Javascript code much denser than that of Java and with very few classes, if any. Object Oriented Programming is still possible in Javascript, but much less pronounced.
When layouting your display, you need to think in terms of HTML and CSS. The best approach is to modify only the document structure (adding/removing elements or HTML classes) using the Document Object Model (DOM), and leave all CSS in an external file. In any case, you need to know CSS enough to be able to layout your page. Modern browsers support canvas, but it has no built-in layouting engine - its closest Java relative is JCanvas - just a blank area where you can draw graphics primitives - or a WebGL canvas - where you can place triangles in a 3D space.
When designing your own API, you need to know which operations might need to be asynchronous. If they are, either take a function as an argument (a callback), or return an object that does (a promise).
Except for the this variable, Javascript is function-scoped and lexically scoped and has closures. If a variable exists in a surrounding scope, it can be read from and written to - even from within a function that is only defined in that scope and called much later. In Java, you can't close over non-final function-local variables.
However, you need to be careful about timing - don't think you can just assign to a variable within a callback and use it outside. When you try to use it, it won't have been assigned to yet. Many have tried to cheat the time this way, and failed.
When the user leaves your page, it's a game over. If you want to remember anything past that point, you need to store it somewhere, be it cookies (very little space, outdated API), localStorage (decent amount of space, not supported by very old browsers) or the server (lots of space, but talking to the server when your page is being shut down is tricky).
the DOM API is often criticised, but there are several frameworks and libraries that ease the usage of it, of which the most popular is jQuery, which also handles browser inconsistencies, improves the AJAX API, event delegation (you can't attach an event handler to an element that doesn't yet exist) and includes an animation engine (though modern CSS is almost as powerful and often easier to use).
I think java web start could help you
http://www.java.com/it/download/faq/java_webstart.xml
I suggest you to take a look at Java Web Start. It offers you a possibility to start your application software for the Java Platform directly from the Internet using a web browser.
For more details see: Java Web Start
Nowadays Web Start is not a good option since, the user needs to have JVM installed and with all the vulnerabilities buzz around Java is more difficult to convince users to download it. The latest versions of JDK 1.8+ include scripts to pack your application along the jvm runtime in just one installer: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/
For using your application in a browser like an applet, you can use Bck2Brwsr or TeaVM both can run java applications in a browser without Java Plugin. Bck2Brwsr also uses Java Plug in if it is available.
You can also use GWT to compile your Java application to JavaScript. Note: Swing is not supported.
Regards
I am developing an client-server application where client gets updates every second (lets say 1000 fields) . I also need to draw waveforms from at client side.Server is already existing.
For this type of application which will be better ? GWT with intermediate server or Java Web Start which directly connects to existing server in terms of performance, difficulty to code ?
I don't see that much difference among them. I'd even say that they are separate things. Webstart is how your client will get the app: from some site.
Webstart is a bit easier to mantain, since your client will get it everytime it starts.
Deploying a stand-alone can be a bit harder, depending on your infrastructure.
Performance: just the "download" part of the webstart can be a bit heavier. I thinkg performance is almost the same, after ir began to execute.
Difficulty to code: it's just a matter of experience. Your code in both them will be almost the same, since they'll do the same things.
Mantain / upgrade : easier to mantain and upgrade the Webstart than installing a client on each machine.
Consider using a JFreeChart DynamicTimeSeriesCollection, seen here, distributed via java-web-start. A thousand fields in a scroll pane is possible, but JList or JTable would be considerably more efficient.
If the server already exists, the issue is more about the best way to connect it to the client, than whether or not to use GWT. For example, if you want server-push rather than client-pull for the updates, that changes things somewhat. However, assuming you need to do some vector graphics, and pull information from a server (I'll assume that you can use either JSON or XML to get server information), you could use several different JavaScript toolkits to do this directly, without Java or GWT needed at all.
For this type of application, Dojo would be one fair option. It has fairly good portable vector graphics, it's pure JavaScript and it is finally at a stage where documentation is OK. GWT would be a useful bet if the server didn't already exist, and where you wanted a decent set of controls usable on the client side. But for rich graphics, I'd look at JavaScript options like Dojo, Raphael, or even jQuery. Dojo does support line charts, and that might be a good basis for waveforms.
Some of this depends on the nature of the server. If it uses a different protocol from HTTP, or doesn't really provide easy JSON or XML access, you're probably better looking at a client-server package that does make the bridge between client and server simple.
GWT might be an option here, but it is designed more for robustness than for very fast development. And if you are fitting with an existing protocol, it could be a fair amount of work.
Hey,
i've a simple question.
Task:
Program a backup system which can be used by server-, or desktop-systems. The backup system should include a graphical configuration and status view. The programming language should be Java.
Question:
Would you use a web interface, which will solve these jobs or would you create a GUI in Swing?
My thoughts:
- The web interface has the advantage that is is accessible from everywhere (server - configuration made easy without any additional software on the client side).
- The GUI has the advantage that it is more responsive than a web interface and will maybe look more professional on a desktop-system than, the web interface version.
Which solution whould you choose?
Thanks!
The desktop vs. web app discussion usually depends on who would use the application, and from where. If it's always going to be used by the person sitting at their desk (or at the desk of the server), a desktop application is a good choice. If the user may be remote a web application is the way to go.
Another consideration is deployment. Is this going to be deployed on one or two machines, or does it need to be installed / available to 10's, 100's or 1000's of users? Deployment and updates across hundreds of machines can be onerous for desktop applications, but a non-issue with web-based apps.
Generally speaking, you can give a much richer experience with a desktop app. In this case, however, "rich" isn't really a requirement. You're going to have a few buttons, perhaps a window showing a log of some sort, and that's about it. So from a usability perspective you can probably create a compelling UI using either method.
If deployment and a rich UI don't really factor in, pick the one that either a) you know well, so you can do a good job, or b) want to learn assuming you have the time.
Since the actual question you asked was "which would you choose", personally I'd choose a desktop GUI based on the little information provided in your question.
Yeah Bryan is totally right. Choose the solution you prefer, since you are the developer :)
I'd prefer the web solution, because I love to play around with these nice Web 2.0 AJAX/JS things. Also there are at the moment a few new Browser Developments, which will make it possible to use an webapp as desktop app.
Basically, it's really no matter which variation you choose.
I did serious Swing work in the past but I see less and less the incentive to use "fat client" technologies with today's web based UI (Ajax, JQuery, HTML5 and efforts like html5boilerplate.com to make them work on older browsers). The browser is the present and future of rich UI, specially as more software makes the move to the cloud.
I have a new application to write, and the timeline is tight - I'd like to overview the requirements and why I'm considering Portlets over Servlets; however, I have no experience with Portlets and therefore would like someone who is familiar to let me know if I'm missing anything, or if I'm doomed to spend too much time learning the new technology.
Project Requirements Overview :
I need to build a system that allows clients to build simple websites through our own UI (the building tools must be completely customizable as I'm working with a talented design team) - think of a "easy as 1,2,3" page builder where you specify templates, content, etc. Of course we also need to be prepared to handle special requests where clients or internal people can tweak the pages. Also, we will offer special components and pages that interact with our back-end system.
Each client website must be linked to a separate domain
I should be able to create multiple interfaces for editing pages and content - so that more advanced users are able to make more advanced changes
A web designer without programming skills can create templates for the look and feel of the sites - while developers can then add the dynamic functionality
Why I'm Considering Portlets :
As I drew up extravagant designs, the one thing I keep coming to is realizing, this is going to be difficult to deliver quickly, and the quicker I deliver, the more likely I am to have coded myself into a corner. So I wanted to be able to manage aspects of the application separately, but just don't have the time to do so (since it would be entirely on me to create that system). Also, in order to keep on time, I will need to delegate parts of the project carefully, if its totally home built I need to be REALLY careful what I delegate. Then I found out about "liferay" which lead me to investigate portlets.
So basically the Portlet architecture doesn't seem to prohibit anything I need, plus we can add all our special needs as hot deployed portlets - pages can be created as HTML and enhanced with Velocity - and if some requirements change, there is a standard I've adhered to and therefore can make changes to configuration. I may even want to use liferay as it does nearly everything I want (although I would need to provide a much simpler page editing interface).
Conclusion :
So that's the project requirements and why I'm thinking about going for portlets, but I'm not sure if it's really a fit, or if it just SEEMS like a fit, does it seem reasonable to those of your familiar with Portlets?
There's nothing you mention that speaks against adopting portlets - quite contrary: Sounds like a good fit.
The only tricky part might be that you don't have any portlet experience, so estimation will likely be a bit off while you learn this environment, but this would apply to every environment that you don't know yet. Compared with a servlet approach you'll start with quite a lot of functionality out of the box, so it sounds completely reasonable. And you don't even need to maintain this functionality yourself...
If you can you might want to consider getting trained in the environment of your choice to get to speed quickly. (You tagged the question with "liferay" and Liferay offers training all over the world - Disclaimer: I work for Liferay)