Writing a properties file with an applet

[Derrick Albers]

I am trying to use Properties through an Applet. I have signed the Applet and I am able to read a file from the getCodeBase() URL, but I am not able to write this file. I know that I can update the java.policy file but I am looking for a way around because everyone that viewed the applet would nee to update the policy file. Is there anyway to write without changing the policy, or can I write something for the end user to run that would automatically update the policy file on that computer so they could read write the properties?

Thanks
-Derrick

[Paul Clapham]

This "file" is on the server, is it not? It must be if you're getting it from the applet's code base.

So to write the file, the applet would have to upload the data to some server component which took care of actually writing to that file. You can't just write a file to a different computer (i.e. your server), the security issues should be obvious. You need something running on the server which accepts the file transfer. If you're in the Java ecosystem then a servlet might answer. Google keywords: file upload servlet.

You might also consider what happens when you have two, or two hundred, users of the applet all updating that file. What's the rule? Last update wins? What happens with two near-simultaneous updates?

[Derrick Albers]

Thanks for responding, actually I need something local, I have tried cookies, but, well that sucks because the site is limited to 20 cookies and there are several object states that I need to save, I really need local file access with out each user needing to understand how to update the java.policy. I thought signing the applet would be the answer, but they would still have to access the java.policy file and this isn't a real option. Any suggestions?

Thanks,
-Derrick

[Lester Burnham]

Derrick Albers wrote:I thought signing the applet would be the answer, but they would still have to access the java.policy file and this isn't a real option.

Can you elaborate on why you think signing isn't the answer? All users can fiddle with their local policy files if they so choose, but very few do so, especially if it isn't required.

[Derrick Albers]

I can't ask the use to change anything on their end. I signed the applet and I am still denied the ability to write a props file on the local system, i.e. c://myprop.props. Everything I have found tells me that I have to sign it, and that the user will have to add that applet to the java.policy file. The user base is a click and go base so they can't be asked to alter their systems. Accepting the signed applet was a huge decision, editing a file would be out of the question.

[Lester Burnham]

No, that's not how it works; signing an applet is sufficient to grant it all permissions. (And it is really the only way - asking an average user to fiddle with policy files is a non-starter.)

If signing by itself won't do, have a read of https://coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem and apply the privileged code tweak it describes; that should do the trick.

[Derrick Albers]

That's great! Thank you for the help I am going to try this right now.

[Paul Clapham]

As an aside: have you considered using the java.util.preferences package to store these properties? This (at least for Windows) puts data into the registry. You'd still have to sign the applet to do that, but you wouldn't have to deal with the possibility of not being able to create a file in a particular place because of directory permissions and so on.

[Derrick Albers]

Problem there is that it is run on MAC, Linux, and Windows. jre 1.4, 5, and 6

[Paul Clapham]

Then on the non-Windows boxes the preferences are stored somewhere else. It works there too, I just don't know the details.

That would also be simpler for you because it abstracts all the details of exactly where to put the preferences away and you don't have to deal with that.

[Lester Burnham]

Paul makes an excellent point. The Preferences API was introduced in Java 1.4, so it works on all platforms you mention.

[Derrick Albers]

Thank you guys for the help I am going to use this to do it, I will let you know how it turns out.

[Derrick Albers]

I ran into a problem with using the privlaged code:

AccessController.doPrivileged(new PrivilegedAction() {
        public Object run() {
            // perform the security-sensitive operation here
            return null;
        }
    });

How can I pass the string into this and get the return? I need to use prefs.put(key,value) and return the string value from prefs.get(key)

[Lester Burnham]

A class like the following would help; whether a get or a put is performed depends on whether or not a null value is passed in for the value. You'll need to make the "prefs" object in your applet code final, or the compiler will complain.

private class MyPrivilegedAction implements PrivilegedAction {

    private String key, value;

    MyPrivilegedAction (String key, String value) {
        this.key = key;
        this.value = value;
    }

    public Object run() {
        if (value == null) {
            // call some applet method that does something with the result of prefs.get(key) here
        } else {
            prefs.put(key,value);
        }
        return null;
    }
}

...

AccessController.doPrivileged(new MyPrivilegedAction(key, value));

[Derrick Albers]

That worked like a charm, thanks again to everyone for all of your help!

Thanks
-Derrick

[Derrick Albers]

Well after I get that working they wanted it changed....of course So now I have to write a file that is to be named what I given from the code and place it in the a directory on the client side computer, is this possible from an applet?

[Paul Clapham]

Sure. It would have to be a signed applet, of course, and there are always potential problems such as the applet not having the right permissions to write into that directory and so on, but yeah, signed applets can write to the client's file system as much as any other application can.

[Derrick Albers]

Yea I got it, I had to get the URI.toURL().openStream() to read it, but I figured it out Thanks for the response though I appreciate you guy always helping out!