The error message generally produced by JNLP clients, not least Sun's/Oracle's own Java Web Start client, are generally oriented towards end-users and not very helpful for figuring out the root cause for why they appear.
For instance, when I try to run my JNLP program right now with Oracle's JNLP client, it simply says to me that "The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel." NetX hasn't been much more helpful either, but it also seems to implement much less of the security model than Oracle's client does, so it would only help so far even if it were.
Is there any good way to find out what security problems it is that I'm actually having? "Read the documentation" is of course the easy answer, but the security model seems rather complex and incorporates many parts. Is there some kind of "lint" tool for JNLP out there that can list the problems I'm having? Or is there some way to run the JNLP client in some kind of debug mode?
I'm not really asking for help with this particular, specific problem. I've been having other problems previously, too, and have mostly only gotten past them by mere guess-work and getting lucky, and I'm still not sure I've solved them correctly.
There is an option to debug the Web Start using -Xdebug
Also this link might be useful if there is any issue while enabling debug
Related
I'm deploying a JavaFX application and am not quite sure what does and doesn't need to be signed. Here are my thoughts:
- Installation file:
This obviously needs to be signed.
- The EXE that launches the application:
I believe this needs to be signed, although it feels a little bit funny because it isn't my code.
- My JAR files: I believe that these also need to be signed, although I'm not sure if anything terrible happens if I don't.
- Library JARs that I've grabbed off the internet: I don't feel like I should sign these. Is there any reason to?
- Java runtime:
I'm guessing there's no reason to sign this, and I'd probably violate some agreement if I do.
- JNLP file:
Not using this, no reason to touch this.
Have I looked at this properly? Am I signing the correct files?
A friend of mine has a saying " it's not what you did... it's what you can prove in court. "
With this respect, I advise you to look at this problem from a legal point of view and assume the worst possible context it can apply in; i.e. you becoming legally accountable after someone tampers with your software.
Digital signatures are designed especially for these types of problems.
With this respect, let's split your answer into 2 different classification parts:
the software you're releasing - includes your jars, jnlp, bundled .exes, etc.
all of these must be singed in order to ensure that you can't be affected by any unauthorized tempering with your own code. It doesn't matter whether or not you've released that jnlp. If someone generates an invasive one and it's traced back to you, your failure to authenticate your own released version of that jnlp will not be ok.
the software released by other people. - includes everything which you're using in order to get your system to work. (jre, libs)
when using something like this, it's a good idea to make sure you're using a genuine copy of whatever your lib manufacturer has released. Use their checksums/signatures/etc. to validate and verify their software integrity upon demand. You have to read their liability and disclaimer statements and in the event they fail to provide one themselves.
In general it is a good idea to place as little trust as possible when it comes to software sources other than yourself. Unfortunately, there are many compromised or malicious libs out there which are in fact security risks.
it is always a good idea to make sure you're releasing a downloaded lib which is certified by an external issuer and as such cannot be held responsible for any malicious code detected within.
To answer your question... it really depends on the client endpoint and the likelyhood of you getting sued for providing them with a security risk (i advise you to always expect this to be 100%). If you're liable for damages... you need to proceed accordingly.
In short... the best possible answer to this quesiton is to do whatever is possible to cover yourself in the event the worst happens.
Does your application need elevated privileges? If the installer is targeting Windows you wish to install the application to Program Files, then your installer will need to be signed. Without it, Windows will give a yellow banner during privilege escalation request.
So - sign your installer.
The exe that launches the application should ideally be signed as well. But for a java application, this is perhaps a mute point. Signing the exe is easy enough, that I'd just do it anyways.
Sign launcher exe - Optional, but I'd do it
Jar files. This is an interesting one and depends on what you goal is. Ie, the OS and the end user are probably not going to be aware of the signed or unsigned nature of your Jar. Therefore you will probably have to verify the integrity of the jar yourself. See https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html
Perhaps the launcher application can perform the integrity checks before the launch step ?
Library jars, Similar to the case above, if you want to make sure that no one has dropped in a diff jar into your application or some such use case, you will need to verify this yourself.
Java Runtime If you shipping this, is this not already signed by Oracle or your JVM vendor ?
I am a Java developer doing my first steps with JavaScript.
In the next couple of months my Javascript code is going to be pushed to production and had a question about code and application monitoring.
With java (or any major programming language for that matter) there are tools to monitor the application health - logs, exceptions, asserts.. Which once a bug is being opened, provides me more information about the server state.
Or scanning the logs I can tell if there were any issues with the applications.
How do I know what my customers are doing with the UI? How do I send exceptions or logs to my client? Should I do it or it is unnecessary overhead?
What are there coding practices or tools that I can achieve it on the JavasScript side? links to good articles/tutorials around this topic will be highly appreciated.
Most modern browsers have a console available with ctrl-shift-j or ctrl-shift-k (at least on linux), though the grandaddy of such consoles is Firebug, an extension for firefox (et al, but primarily firefox:
http://getfirebug.com/. Especially important to debugging is the use of console.log to write to these consoles for figuring out how far you've gone in the script.
EDIT: missed the bit about server things. I would suggest avoiding nodeJS until you're a bit further in with normal JS.
Lastly, use libraries after you need them if you want a deep understanding of the language
I am used to adding logging to standalone Java applications and writing the logs to the files using log4j and sl4j. I am moving some applications to a Java web start format and I am not clear on what is the best way to perform the logging to monitor the behaviour of the application. I have thought of two options
Write the log to the local machine and provide an option to send the information to the central server under some condition (time, error etc..)
Send the output of the log to the server directly
What is best practice?
I've seen 1. implemented by many programs.
But 2. seems bandwidth intensive, intrusive, and overkill.
Agreed, 2 seems like it's not such a good option. An error with webservices wouldn't be logged in that case. I was wondering if there was any other option but I can't think of any.
I was thinking of entirely local sources of problems connecting to the server, but good point.
What is best practice?
Stick with the majority and use method 1. Unless you have a marvelous inspiration about how the entire logging/reporting system can be improved, I'd go with "tried and tested". It is likely to be easiest, best supported by existing frameworks, and should your code falter, has the greatest number of people who have 'been there, done that' to potentially help.
Our development team hosts many different applications both .Net and Java based. Currently, we handle our error logging with Log4J and use emails to alert the development team when problems arise. Currently, we get thousands of alerts a day and it's becoming a little tedious to maintain.
We've been discussing creating a central dashboard for all our apps. The ideal tool would track errors, warnings, info etc. over the life of an application (it doesn't necessarily need to be db driven). The idea is that the data can be viewed on a dashboard, drillable to specific errors with the capability of alerting via emal when triggers and or thresholds are met.
Elmah is good for .Net but we need a tool that could also work for Java EE? What is the best way to go about this? Should we:
Just use Elmah for the .Net apps and find something similar for Java and build our own dashboard to create a united look & feel?
OR
Is there a tool that already exists that we can leverage to do this cross platform?
I've tried looking in Sourceforge but it's difficult to describe what I'm looking for.
I don't think you have a logging problem, I think that you have an integration problem, no matter if it is logging, or any other area your root issue is the same... How do I make my completely different components talk to each other?
There is a lot of approaches, but probably the easiest to implement for different technologies is Web services or REST... You will probably need to have a central logger that you need to implement independently, and then build a Web service/REST interface to which you are going to have to connect to...
Maybe a different line of investigation for you is to see if there is a logging product out in the market that takes web service calls... If that's the case, you only need to change your components to make a service call every time.
Something else that you need to consider is that your remote logging should never superseed your local logging, that's it do both, the reason is very simple, remote calls can fail, so code as if they will fail.
We have been using http://www.exceptional.io/ for error tracking for some time now: it's cheap and extremely simple.
To report errors you just post a json document to its endpoint.
We have a Java web application and we'd like to set up some basic monitoring with a view to expanding this monitoring in future. Our plan is as follows:
(1) Collect generic information (e.g. memory and threads) about the virtual machine of the web container that application is running in.
(2) Monitor the "state" of the application. This is rather vague but at the least we'd like to see if the web application is still alive and can respond to requests.
(3) In the future we'd like to collect more information that is specific to our application. Again this is rather vague but you can assume that we might want to make certain statistics collected internally by the application available to the support staff.
Usually the web application will be deployed in a Tomcat 5.5 or 6 environment. A quick bit of searching on the web shows that JMX can be enabled for Tomcat and that JConsole can then be used to connect to the server. This gives us lots of basic information that solves point (1). Also, some information is available in the MBeans section for "Catalina" and drilling down on this I can at least, for example, see how many requests a particular servlet has received. This is not quite what we want for point (2) but at least gives us some information. There seems to be quite a lot of information there but it's rather difficult to interpret using JConsole. Perhaps there is a better tool for interpreting the MBeans exposed by Tomcat.
For point (3), it seems, at first glance that we could write our own MBeans and then make these available to something like JConsole. Personally, this would involve me learning about JMX which I'm quite happy to do but I have a concern. Having looked around I notice that most of the textbooks on the subject haven't been updated for several years and the open source tools seem to be languishing without recent updates. So my main question is a simple one. What are your opinions on JMX? Does it have a future or is it/has it been superseded by something else? Given we already have our web application but we're starting from scratch for the management console, should we choose JMX or is there something more appropriate with a better future ahead of it?
I ask this question with no personal axe to grind, I'm simply interested to hear your opinions and experiences. I'm sure there's no one correct answer but I think an informed discussion would be useful.
Thanks in advance,
Adam.
JMX is certainly a good solution here. I wouldn't worry about it languishing. Most enterprises I've worked for recently use (or have plans to use) JMX, and I'd have to hear a pretty convincing argument before choosing something else in the Java world. It's easy to write clients (monitoring solutions) for it and you can return complex data very easily indeed. Most 3rd party components support monitoring via JMX as well.
Note that you may want to consider integration with any existing management solutions (e.g. Nagios, BNC Patrol, HP Openview etc.) as well. They may not be so Java-aware, but rather prefer tests like simple HTTP connectivity for testing if a web-site is up (easy using Nagios), or integration using SNMP (which Openview talks natively).
If applicable to your situation (Java 6 update 10 JDK or later, plus on the same machine) then consider using jvisualvm instead as it can dig even deeper than JConsole.
You may find that the easiest way to do what you need is a plugin to jvisualvm knowing your application