We Keep Coding

Prevent users from downloading and using my Java applet manually

I've written a Java Applet and run it from my website.
In the long-term I plan to charge money per use of this applet.
The question is, is it possible to prevent users of downloading my code (i.e. my jar file) and then running it from their home, without paying?
(In this I don't mean decompile - I use obfuscator. I mean someone can use it easily without even decompiling it or understand it's code...)
I thought about using a changing password which the server sends to the applet using the HTML, but I thought - maybe someone knows a standard way of achieving my goal instead of reinventing the wheel??
Thanks..

There are several ways you can do this.
You can put code like this at the beginning of the applet's init method, assuming it creates some components:
if (!getDocumentBase().getHost().equals("yourhost.com")) {
JOptionPane.showMessageDialog(this, "You can't download it");
return;
}
Of course, you have to change yourhost.com to your actual website.
Pros:
Easy to implement, no server-side code
Cons:
Can be decompiled and the test can be removed
Someone could trick their computer into thinking it is "yourhost.com"
You can put all of your code on the server. For this, I will assume that your applet computes the cube of an integer.
Then the code looks like this for your applet:
public class CubingApplet extends JApplet {
private JTextField intField = new JTextField(3);
private JLabel output = new JLabel();
public void init() {
setLayout(new GridLayout(2, 2));
add(new JLabel("Enter an integer: "));
add(intField);
add(new JLabel("The cube of that is: ");
add(output);
intField.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
output.setText("" + getCube());
}
};
}
private int getCube() {
try {
int n = Integer.parseInt(intField.getText());
InputStream response = new URL("http://www.yourhost.com/dosomething.php?n=" + n).openStream();
String sResponse = new BufferedReader(new InputStreamReader(response)).readLine();
return Integer.parseInt(sResponse);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
I must stop writing this right now, but I will add server-side code at the earliest opportunity.
By the way, even if you obfuscate, and it can't be decompiled, it is possible to recognize what these kinds of protection schemes look like, and remove them. So any protection scheme you devise can be short-circuited, because no obfuscation is bulletproof.

If the user's computer does all of the work of the applet, then it is impossible to prevent them from downloading a copy of the code. The browser has to download the code in order to run it; all the user needs to do is tell the browser to save the file or to use another program that will. The only way to prevent the user from being able to use the applet offline is with DRM. Perhaps you can include a check to your servers to ensure that the usage is valid; while the program is free the usage would always be valid but later you could verify it online. This is vulnerable to decompilation and modification to remove the DRM. Another option is to do some of the computation on your server, using code that is never exposed, but this of course has the downside of requiring you to maintain servers to do the calculations, which can be expensive.

In short no. Anyone can look at the webpages source code, find where the applet is stored and directly download it. If your product is not limited to an applet then it would probably be better to have it as an executable and sell that.
If you really need for it to be an applet that is payed for every time without being downloadable you could run all the actual processing on a separate server, construct what the screen would look like on the server and then send that image to the client (whos is using the applet). You would then display that image on the applet. Bear in mind that if your program would accept user input the applet would have to send that input to the server to be processed to.

The best way to do this would be to have a program on the serverside that provides data that is necessary for the app to do anything useful. They are only allowed to connect the applet to this if they have purchased an account (they have to log in inside the applet).
Since this is enforced serverside, they cannot bypass the restriction.
This obviates the problem of them downloading and decompiling it, because they still have to have an account to make any use of the applet.
The downside is that will probably require some rewriting of the applet and the creation of an entirely new program for the server.

If you really wish to protect your source code, you can make use of J2EE and make servlets that run on your webserver. The great thing about this is that all the work is done server-sided, similar to using PHP. This means that the end user can only see the output of the program and can not access the program files themselves.
A great article to read on the subject of J2EE servlets can be found here:
Java Servlet
Here is a quote from that page, I think it is exactly what you are looking for:
The servlet is a Java programming language class used to extend the capabilities of a server. Although servlets can respond to any types of requests, they are commonly used to extend the applications hosted by web servers, so they can be thought of as Java Applets that run on servers instead of in web browsers.

If you will implement a login page before the user will be able to use the applet, then you will not need to prevent them from downloading it. Anyone who wants to use must register (buy) from you a username/password.
Additionally you have already using obfuscator to prevent decompiling, which means that it will not be that easy to modify the applet to bypass login.

Slow file dialog in java applet

I have a java applet I am using for uploading from interenet explorer in my web site.
when a button is presse on my site , a javascript function inits the applet and calls the applet's OpenPrivDialog() function.
public void OpenPrivDialog() {
AccessController.doPrivileged(new PrivilegedAction<Object>() {
#Override
public Object run() {
OpenDialog();
return true;
}
});
}
public void OpenDialog(){
JFileChooser fc = new JFileChooser();
fc.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);
fc.setMultiSelectionEnabled(true);
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "Opening dialog", "fe");
int retVal = fc.showOpenDialog(f);
if (retVal == JFileChooser.APPROVE_OPTION) {
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "approved", "");
File[] files = fc.getSelectedFiles();
Logger.getLogger(UploadApplet.class.getName()).log(Level.INFO, "got " + files.length+" files", "");
AddFiles(files);
}
}
this code works, but is terribly slow the filechooser dilog opens, but for a minute is completely unresponsive and then just extremely slow -any idea why?

When I read this post I could picture a horrible experience I had. I needed to work in a software much more complex than yours but in essence it had the same principle: Interacting Java Applet with Javascript running on a web browser.
We faced several issues and I would highlight:
Slow response: similar to what you are experiencing.
Security issue: security checks asking the user to agree with
potentially dangerous code and other issues related with
zero-day-attacks.
Inoperative Javascript calls: rarely our applet could not reach the
javascript code, we never found the reason of this issue and it was
very hard to reproduce.
Browser compatibility: Firefox and Chrome were very standard, but we
faced several problems with Internet Explore and Safari.
It turns out that our applet code was ready in 5 days but the integration with javascript took about a month (we had 4 senior developers working on it) just because our stakeholder wanted it to work with some fancy jQuery components. It was just a nightmare!
Bottom line, we could not do it. Alternatively, we wrote everything within our applet and provided a series of properties that UI developers could use to change the appearance of our applet which worked great and everybody was happy with it.
Therefore, I would advice to do not use JavaScript + Java Applets. Yes, you can use some basic features, but do not go further with it.
Alright, let's talk about your issue. We noticed in some cases that javascript was very slow when calling Java Methods but was never slow when changing Java Propeties. So, we created some Java variables and changed it via Javascript. Next, we watched these variables (maybe in a thread). Finally, we could call the right methods based on these variables.
No, I do not like this approach. But was the only thing that worked for us before drooping the idea of using Javascript with Java Applets completely.
I hope it helps.
Cheers,

How would I be able to open an URL in the same window in java?

This is my current code for the open URL part. How can I modify it so it always opens in the same browser window? This is not javascript.
try{
String url = "www.google.ca"+sn;
java.awt.Desktop.getDesktop().browse(java.net.URI.create(url));
}
catch (Exception e) {}
}
This function is called many times where sn is a random new page on google. How can i replace the current page it opens?

AFAIK, there is no general, portable, way to do this. Depending on the browser and the platform, you may be able to do non-portable things to tell an existing browser instance to open a different page. However, the standard Java APIs don't support this. (For a start, it may not be technically implementable for some browsers / platforms.)
Another approach might be to use an embedded Java browser; see Is there a way to embed a browser in Java?

Implementing a lightweight java webbrowser

This is my first question on Stack Overflow , so if it is bad form please excuse and correct me !
As the Title implies I am trying to implement a light-weight web browser in Java , however I am running into a problem but before I go into details I will provide a brief description of my implementation :
The program consists of the following classes:
GUI (Extends JFrame implements HyperlinkListener) : The graphical user interface
Engine : Does all the actual work
BlackListPolicy (implements CookiePolicy)
I am using a JEditorPane with its content set to "text/html" to display the webpages
Whenever the "GO" button or a link is clicked the Engine gets a URL and then JEditorPane.setPage(URL)
So this brings me to the first part of my question :
The browser is working , however only simple html pages are being displayed
if I go to Google for example If I click a link it works , it remembers my settings (Cookies)
but if a press "Google search" button for example nothing happens , no embedded objects (Flash , applets , etc.) are displayed and other pages are not being encoded properly
My theory is either that JEditorPane can't display such objects and is not a good choice for a web browser , or that I Set the wrong content type for it.
As for part two of my question :
As a cookieHandler I am doing the following:
BlackListPolicy blackListPolicy = new BlackListPolicy();
CookieManager cookieManager = new CookieManager(null, blackListPolicy);
Thus I am using the default CookieStore , which to my limited understanding uses an internal implementation to store Cookies (they are not persistent) which is what I want
However if someone would go on what I would call "an extreme browsing session" storing an excessive amount of cookies would that cause any performance or memory issues or does the default CookieStore handle such cases?
Before you ask , yes I am a student but this is not a homework assignment or even something that is related to my current programing Courses , this is something that I want to implement because I noticed that the best way to learn programing is to write programs
I only need Abstract answers maybe with a link that would send me towards the right direction , if you would like me to post my code I would gladly do so
~Thanks

Your settings are not wrong on your JEditorPane as it only supports a small subset of HTML. If you want something better you are going to have to build an entire browser yourself which definitely is not a small project.

I know this is an old post, but, have you considered using HTMLUnit?
It's a bit complex but I think it's what you're looking for - a fully java based browser library with full JS support.
http://htmlunit.sourceforge.net/

Detect Display Type (Projector) from within the browser

It goes like this, we need to detect if the display is a Projector (or if the system is connected to a Projetor).
the catch is this should be done from within the browser.
so is it possible to do so by using an
Java Applet
Flash
ActiveX (this does constrains to a single browser, so not an option)
searching so far only reaveals display resolution. expecting if there is something still out there. . .
Edit: accecpted answer is for Java Applet approach. hope there may be an easier way through flash...

A normal Java Applet will not be able to tell you whether you're viewing through a projector.
If you can detect whether you're running on a projector from native code then you could code a library up to do so and access it from your Applet with JNI. You'll need to sign your applet and wrap your library loading with AccessController.doPrivileged()
Here's explanation of how that last bit works:
http://download.oracle.com/javase/1.4.2/docs/api/java/security/AccessController.html
By all accounts, Java Web Start provides an easier path for using DLLs from Java though:
http://mindprod.com/jgloss/jni.html#APPLETS

Use CSS.
selector {
property: value1;
}
#media projection {
selector {
property: value2;
}
}
You could use JavaScript to detect the different value. :)
if (element.getPropertyValue(property) === value2) /* Some JavaScript stuff. */