I'm trying to put an applet into a Google site (Because Domain hosting costs money). I've got that working, it is in the site. Now, I'm completely new to this, and my question is why doesn't my applet work?
The first thing I tried was uploading all the files to Google drive and accessing them there (My applet accesses multiple text files [ONLY READS, DOESN'T WRITE]) but that gave me a magic number error because FTP was ASCII which makes the class file all stupid, or so I've researched.
Okay, so I got a website that hosts files and it chooses the FTP (it automatically did Binary for my class files and ASCII for my text files) this made it better, but apparently unsigned applets can't access files other than the class file (I think).
So, I made a .jar for my applet using jar cvf [jar name].jar [blah blah blah, class files I need and text files I need]
I uploaded it to my file hosting site, and alas - Magic number error! 2 something something a lot of numbers. at this point, my HTML code looked like this:
<applet
codebase = "[URL for jar file]"
archive = "[jar file].jar"
code = "[class file].class"
width = ###
height = ###>
</applet>
paranoid that the site's FTP client was messing with my jar, I used FileZilla to upload to my server (an I selected the binary transfer type), which still resulted in a magic number error specifically 1347093252, which is the start of a zip file I believe (If it helps, when I click on the link for this file, it does in fact download).
I've probably done something stupid, but I would like to reiterate that I'm completely new at this.
If anyone could help, that would be awesome;
Thing's I already tried: Clearing my java cache and loading the applet (from here on, assume all the thing listed end with "and loading the applet"), clearing it again, closing my browser, clearing my java cache, clearing my cache - closing my browser - clearing my cache, reloading, changing computers, changing internet connections, changing computers and internet connections.
First of all, an unsigned applet can read files off of the server it came from. If you put dome text files in the same folder as your applet, the applet can grab then. I think the method is something like getDocumentBase to get the directory your applet wad loaded from. What you cannot do us access the local file system.
Making jar files with the command line is a pain. You might want to use an IDE like netbeans to build your project.
Related
I need to write a little Grails (or Java) app that will handle authentication (from our proprietary Single Sign On system) and then once authenticated allow a user to download files. This is very straight forward if I simply include the files in the WAR file of the application, however, I'd like to avoid that since there will be multiple files and I'd rather not have to upload a new WAR file every time we add a new file. Is it possible to accomplish this by having the application be in a WAR file but the files outside the WAR file, if so, how do I configure this kind of setup? We'll be running this on Tomcat.
Yes this is possible. Without knowing all your requirements or what you have tried and why it didn't work work for you the best I can do is give you a general idea of how to accomplish this.
Have a controller that takes an ID of the file that you want the user to download. Based on this key find the associated Domain instance. The domain should store the file name of the file. Then use this file name to resolve the file from the local file system (path configured in your application configuration). Open the file and stream the contents to the browser. Be sure to set he headers correctly to indicate the file name and size.
There are a lot of moving parts involved here but it can be done. Now, if you get stuck on something I suggest you post what you have tried and what's not working about it. Otherwise, the best we/I can do is give you general guidance/advice.
Hope this helps!
Edit
The real key is going to be in the controller for downloading the files. Here is a quick snippet of what that may look like:
String fileName = "something.zip" // should come from your domain instance
String filePathAndName = "/downloads/${fileName}" // should come from your configuration
response.setContentType("application/octet-stream")
response.setHeader("Content-disposition", "attachment;filename=${fileName")
// this will actually buffer/stream the file in 8k chunks instead of reading the entire file into memory.
org.apache.commons.io.IOUtils.copy((new File(filePathAndName)).openStream(), response.outputStream)
response.outputStream.flush()
response.outputStream.close()
How do I download multiple files at once from a browser without combining them into single file? I found all kinds of multiple file uploaders, but downloaders are missing. There is only JUpload, but it's old and became buggy recently. I believe both Java and Flash can do this: select a folder at client's HD and download everything there.
The only solution I can think about is a performing multiple AJAX calls to each file separately. All this calls may be invoked by single click of user. This will look OK in Chrome because it does not ask (by default) where to put the downloaded file and put all files into pre-configured download directory.
I think that in Firefox the user will see pop-up that asks what to do with file (download or open) for each file separately.
MSIE will ask where to save each file.
Bottom line: this solution will look good in Chrome only. Other browsers should be configured properly.
I'm currently developing an application for a company which includes livescoring. The XML-files I access (from the net like: "http://company.com/files/xml/livescoring.xml") are not intended to be public and should only known to me.
I was wondering if it is possible for anyone to decode the .apk file and read my original .java files (which include the link to the XML files).
So, I renamed the .apk file to .zip and could access the "classes.dex", which seemed to include the .java files (or classes). Googling led me to a tool named "AvaBoxV2" which decoded this "classes.dex" file. Now I have a folder including an "out" folder where files named .smali exist. I opend one of these with an editor and finally there is the link to the xml file. Not good. :(
Is there a way to encrypt my app or the classes.dex file? I don't want to tell that company, that anyone can access the original xml-files. Maybe signing the app probably helps?
Also, do you know a really noob-friendly tutorial to prepare apps (signing, versioning,...) for Google Market?
Thanks in advance!
The .java source code is not included in the APK.
It is possible to disassemble the Dalvik bytecode into bytecode mnemonics using a tool like baksmali, but there's no way a user can recover the original .java source.
Furthermore, you can use a tool like proguard (included in the Android SDK) to obfuscate your byte code, making it hard to interpret the behavior of the disassembled bytecode.
You can make small tricks too, like storing the link string in some sort of obfuscated form, and then de-obfuscating it at run-time in your app (a simple example would be to use base 64 encoding, but someone could probably reverse that quickly if they wanted to).
That said, it's pretty trivial for someone to run tcpdump and sniff the network traffic between your device and the server, and get the URL that way, so there's no way to completely prevent anyone from getting this value.
Yeah, its impossible to fully prevent something like this. Its the same on a desktop application, or any other application.
As mentioned, obfuscation will help, but people who are persistent can still get past it. Especially for something like a url like that.
One solution of making it much more tricky for hackers is to use PHP on your webserver and some sort of token system to determine if the request is coming from your app or not... That would get a bit tricky though, so I don't really suggest it.
I want to build a simple file uploading applet in Java. It will be used to upload files to a regular linux web server. So if someone went to:
http://site.com/file-upload-applet
And uploaded a file there via the applet, it will be accessible at:
http://site.com/uploads/your-file.jpg
The user should be able to click 'Browse', and then look through the folders on his computer ,and be able to select as many files, or every file in a folder, if he wanted. Then, when he hits upload, he should be shown a progress bar while the files are uploaded.
Any thoughts about this, and how this could be accomplished in Java as an applet? I will just need some pointing in the right direction, such as which Libraries to use.
You'd need to have a signed applet, as unsigned applets do not have access to the filesystem.
I found an article about signed Applets.
As for the other components, you'll most likely need a JFileChooser, JProgressBar, and a JButton (that uses Apache HttpClient's PostMethod with a MultipartRequestEntity that wrape the JFileChooser's file in a FilePart).
I used the Apache Commons File Upload, and it worked like a charm. It took away most of the problems I was worried about, and was very easy to use.
I need some ideas on how I can best solve this problem.
I have a JBoss Seam application running on JBoss 4.3.3
What a small portion of this application does is generate an html and a pdf document based on an Open Office template.
The files that are generated I put inside /tmp/ on the filesystem.
I have tried with System.getProperties("tmp.dir") and some other options, and they always return $JBOSS_HOME/bin
I would like to choose the path $JBOSS_HOME/$DEPLOY/myEAR.ear/myWAR.war/WhateverLocationHere/
However, I don't know how I can programatically choose path without giving an absolute path, or setting $JBOSS_HOME and $DEPLOY.
Anybody know how I can do this?
The second question;
I want to easily preview these generated files. Either through JavaScript, or whatever is the easiest way. However, JavaScript cannot access the filesystem on the server, so I cannot open the file through JavaScript.
Any easy solutions out there?
Not sure how you are generating your PDFs, but if possible, skip the disk IO all together, stash the PDF content in a byte[] and flush it out to the user in a servlet setting the mime type to application/pdf* that responds to a URL which is specified by a link in your client or dynamically set in a <div> by javascript. You're probably taking the memory hit anyways, and in addition to skipping the IO, you don't have to worry about deleting the tmp files when you're done with the preview.
*****I think this is right. Need to look it up.
Not sure I have a complete grasp of what you are trying to achieve, but I'll give it a try anyway:
My assumption is that your final goal is to make some files (PDF, HTML) available to end users via a web application.
In that case, why not have Apache serve those file to the end users, so you only need your JBOSS application to know the path of a directory that is mapped to an Apache virtual host.
So basically, create a file and save it as /var/www/html/myappfiles/tempfile.pdf (the folder your application knows), and then provide http://mydomain.com/myappfiles (an Apache virtual host) to your users. The rest will be done by the web server.
You will have to set an environment variable or system property to let your application know where your folder resides (/var/www/html/myappfiles/ in this example).
Hopefully I was not way off :)
I agree with Peter (yo Pete!). Put the directory outside of your WAR and setup an environment variable pointing to this. Have a read of this post by Jacob Orshalick about how to configure environment variables in Seam :
As for previewing PDFs, have a look at how Google Docs handles previewing PDFs - it displays them as an image. To do this with Java check out the Sun PDF Renderer.
I'm not sure if this works in JBoss, given that you want a path inside a WAR archive, but you could try using ServletContext.getRealPath(String).
However, I personally would not want generated files to be inside my deployed application; instead I would configure an external data directory somewhere like $JBOSS_HOME/server/default/data/myapp
First, most platforms use java.io.tmpdir to set a temporary directory. Some servlet containers redefine this property to be something underneath their tree. Why do you care where the file gets written?
Second, I agree with Nicholas: After generating the PDF on the server side, you can generate a URL that, when clicked, sends the file to the browser. If you use MIME type application/pdf, the browser should do the right thing with it.