This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Access denied error for midi file in same directory as applet!

 
Sam Foletta
Greenhorn
Posts: 4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi! First time caller, long time listener.

I'm getting an access denied error trying to load a midi file on the server, in a subdirectory of the applet's folder. As in, the applet root/ffp.class, on webpage root/ffp.htm, is trying to access root/mid/wm0.mid, and is denied access.

It works fine when I run the applet on my hard disk, but run from the server it throws an AccessControlException (access denied). This is odd, because I can put the same midi file into an AudioClip and run it with no problem. However, I don't have much control over playback with AudioClip and prefer to use a midi sequencer. I'm trying to load the midi file as a FileInputStream which, again, works fine when I run it on my hard disk, but doesn't work once I upload it onto the server.

Shouldn't the applet already have access to files in subdirectories without modifying permissions? Especially if the applet can already access the same files as a different data type? I feel like I'm missing something here.

The code is basically the following:





The line that calls MidiSystem.getSequence throws the following error:





Would very much appreciate any help.
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't use file I/O in this situation. Those classes will try to access the client file system, and that's out of bounds for applets.

You'll need to use the MidiSystem.getSequence(InputStream) method like this:

URL fileURL = new URL( getCodeBase() , "mid/wm0.mid" );
InputStream is = fileURL.openStream();
 
Sam Foletta
Greenhorn
Posts: 4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, I tried that, getCodeBase() threw a NullPointerException so I moved that line from the constructor to init(), but now I get this:



I tried signing the applet, no luck there. Do I need to use privileges? This seems so excessively problematic for loading a midi.

 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It should not be necessary to sign the applet, nor to use privileges. "www.cwahi.net" is the server where the applet originates from?

By the way, you shouldn't use constructors in applets at all - that's what the init() method is for.
 
Sam Foletta
Greenhorn
Posts: 4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, cwahi.net is the same server, the midi is in a subdirectory of the applet's directory.

I tried calling getSequence with InputStream, URL, and File inputs with the same results, even tried skipping the sequence altogether and calling setSequence with an InputStream, no luck. I placed the call in a PrivilegedAction and signed the script just to try everything. Always an access denied error.



UPDATE:
Picking through the console at a higher trace level, I noticed that other resources were being redirected to "stopit.php". When I opened it up in Firefox, it brought up a page that states direct/hot linking is not allowed. It looks like the host server is blocking the applet's connection to these files thinking that they're being linked to by a foreign web site. Yet image files still get through somehow. Hmm...

Any way to get around that?
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The server is *probably* looking for a REFERER header (which a web browser would send if the file was linked from a web page). If that's the case then it gets slightly more tricky, but something like this should work:

It could be something else about the request that the server doesn't like, though - the server admin should be able to tell you what.
 
Sam Foletta
Greenhorn
Posts: 4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're absolutely right. Just added a "toString()" and it worked like a charm.

Final code looked something like this:



and later...




I ran into the same problem with AudioClips, actually, and since they only accept URLs and not InputStreams I assume this fix won't work and I'll have to use Clips and AudioSystem.

Anyways... thanks for the help!
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic