folderdepth still allowing deeper files

Upload core product.
centdir
Posts: 10
Joined: Mon Jul 06, 2009 1:40 pm

folderdepth still allowing deeper files

Post by centdir »

Hi! I've set folderdepth=3 but the applet is still allowing users to upload files that are deeper than 3 folders deep. Here's a part of my .js file settings:

document.writeln('<PARAM NAME="scriptable" VALUE="true">');
document.writeln('<PARAM NAME="resources" VALUE="/cdhtml/i18n">');
document.writeln('<PARAM NAME="url" VALUE="ftp://xxx.xxxxx.xxx">');
document.writeln('<PARAM NAME="param1" VALUE="username">');
document.writeln('<PARAM NAME="value1" VALUE="xxxxx">');
document.writeln('<PARAM NAME="param2" VALUE="password">');
document.writeln('<PARAM NAME="value2" VALUE="xxxxx">');
document.writeln('<PARAM NAME="param3" VALUE="pasv">');
document.writeln('<PARAM NAME="value3" VALUE="true">');
document.writeln('<PARAM NAME="param4" VALUE="accountcreation">');
document.writeln('<PARAM NAME="value4" VALUE="true">');
document.writeln('<PARAM NAME="param5" VALUE="relativefilename">');
document.writeln('<PARAM NAME="value5" VALUE="true">');
document.writeln('<PARAM NAME="param6" VALUE="deleteonfail">');
document.writeln('<PARAM NAME="value6" VALUE="true">');
document.writeln('<PARAM NAME="param7" VALUE="commandmonitor">');
document.writeln('<PARAM NAME="value7" VALUE="120">');
document.writeln('<PARAM NAME="mode" VALUE="ftp">');
document.writeln('<PARAM NAME="timeout" VALUE="120000">');
document.writeln('<PARAM NAME="retry" VALUE="5">');
document.writeln('<PARAM NAME="overwrite" VALUE="true">');
document.writeln('<PARAM NAME="maxfiles" value="25">');
document.writeln('<PARAM NAME="folderdepth" value="3">');
document.writeln('<PARAM NAME="hidebar" value="true">');

The "forward", "post", and "account" parameters are set dynamically via html and cgi code, and I'm also setting setProperty("postparameters","extrarelative") and setParameter("notifyrelativefilename","true") via html/cgi as well.

Are any of these settings conflicting with the folderdepth setting? or am I missing another setting to make the folderdepth limit uploads? (by the way, the "maxfiles" setting does work to limit the amount of files uploaded by a user).

Thanks for any help on this,
Cid

User avatar
support
Posts: 1503
Joined: Sun Jan 27, 2008 6:19 pm

Re: folderdepth still allowing deeper files

Post by support »

Your setup seems correct. Do you have any JavaScript error when the applet is loaded?
folderdepth=0 means files in current folder.
With folderdepth=3 you said it's more than 3, is it unlimited (i.e. all folders and subfolders) ?

centdir
Posts: 10
Joined: Mon Jul 06, 2009 1:40 pm

Re: folderdepth still allowing deeper files

Post by centdir »

I did some further testing and think I have found the problem. Even though the folderdepth is set to 3, it uploads file(s) that are up to 4 folders deep (ie. "/folder1/folder2/folder3/folder4/test.txt" will upload the file test.txt), but does not upload file(s) any deeper. I've set the folderdepth=2 and it does what I originally intended it to do.

Now for my next folderdepth question...is there a way that the applet can notify the user that they've attempted to upload a file that is in a folder too deep? When I tested files that were deeper than 3 the applet didn't give any message (like it does when a user tries to upload more than the "maxfiles" setting).

thanks!
Cid

User avatar
support
Posts: 1503
Joined: Sun Jan 27, 2008 6:19 pm

Re: folderdepth still allowing deeper files

Post by support »

No, it would require a customization. If you need such customization then you can contact support(at)jfileupload(dot)com

centdir
Posts: 10
Joined: Mon Jul 06, 2009 1:40 pm

Re: folderdepth still allowing deeper files

Post by centdir »

Sorry for the LONG post, but I thought I fixed the folderdepth problem (as noted in my previous message), however, I still have some clients uploading files deeper than the folderdepth...sort of...

It seems that when a Vista user selects a file (and NOT a folder) to upload from their desktop (or a file within folder(s) on their desktop), the applet POSTs the entire path from the root (ie. selecting the file "Uploadthis.txt" in the folder "SomeFolder" on the desktop will POST: "/Users/VistaUserName/Desktop/SomeFolder/Uploadthis.txt"). This only happens to the first file uploaded (when uploading one file at a time...I haven't had a client that uses Vista upload more than one file at a time as most of our users upload compressed files and they upload by job# so our server-side pgms move them automatically to the correct job folder).

If, after the first file is done uploading, a user selects another file to upload (and every file after that, and before closing the browser or java), only the filename gets POSTed as it should (ie. only "Uploadthis.txt" gets POSTed when selected for upload). I've only had this issue with Vista users (no problems with our XP or Mac users), unfortunately, I don't have a Vista system to test this on (and it may even occur when Vista users upload files that are not on the desktop, but I haven't run across that issue yet).

I have the following set in javascript so that I get the original filename and path from the POST (to recreate as needed on our server), but generally I only get a path when a user selects a folder to upload, and I don't get the slash at the start of the path as the applet normally POSTs the relative path (ie. I normally get something like "SomeFolder/SubFolder/Uploadfile.txt" from the POST):

Code: Select all

document.FTPupload.setProperty("postparameters","extrarelative");
document.FTPupload.setParameter("notifyrelativefilename","true");
I've checked the IIS ftp logs on our Win2K3 server and noticed that the first file uploaded doesn't even go through the MKD process to create the upload folder (which I set through javascript using the "account" parameter).

For example, here's a log from a correct upload (with some parts "X" out for security):

Code: Select all

19:03:32 XX.XXX.XXX.XXX [1660]USER XXXXXXXXXX 331 0
19:03:32 XX.XXX.XXX.XXX [1660]PASS - 230 0
19:03:34 XX.XXX.XXX.XXX [1660]CWD FTPAppIn/071388 550 2
19:03:34 XX.XXX.XXX.XXX [1660]MKD FTPAppIn/071388 257 0
19:03:36 XX.XXX.XXX.XXX [1660]CWD FTPAppIn/071388 250 0
19:03:38 XX.XXX.XXX.XXX [1660]CWD /FTPAppIn/071388 250 0
19:03:46 XX.XXX.XXX.XXX [1660]created /FTPAppIn/071388/uploadedfile.zip 226 0
in this case our ftp server received "FTPAppIn/071388" from the applet's "account" parameter and correctly detected it wasn't there so it created the folder and uploaded the file into it.

and here's a log from an incorrect Vista upload (with some parts "X" out for security):

Code: Select all

22:31:16 XX.XXX.XXX.XX [1672]USER XXXXX 331 0
22:31:16 XX.XXX.XXX.XX [1672]PASS - 230 0
22:31:17 XX.XXX.XXX.XX [1672]CWD / 250 0
22:33:14 XX.XXX.XXX.XX [1672]created /uploadedfile.pdf 226 0
notice how our ftp server seems to think a "/" was passed from the applet's "account" parameter so it uploaded the file to the root (Note, I am always passing "FTPAppIn/<nnnnnn>", where <nnnnnn> is the job#, as the "account" parameter so that the file gets uploaded and moved to the correct job folder by our server-side pgms).

I am currently using a temporary fix where I check for "/Users/" at the start of the original file path and for "/Desktop/" anywhere within the original file path, however, I'd prefer not to do that in the small chance that someone actually uploads file(s) with those exact text in the path.

Any help or insight on why this is happening would be much appreciated!

Thanks,
Cid

User avatar
support
Posts: 1503
Joined: Sun Jan 27, 2008 6:19 pm

Re: folderdepth still allowing deeper files

Post by support »

on the desktop will POST: "/Users/VistaUserName/Desktop/SomeFolder/Uploadthis.txt").
You get this path in HTTP POST after upload, correct? You never get this in FTP upload?
We've Vista here so we could try to reproduce the problem. Do you have an URL with the full applet running?

centdir
Posts: 10
Joined: Mon Jul 06, 2009 1:40 pm

Re: folderdepth still allowing deeper files

Post by centdir »

support wrote: You get this path in HTTP POST after upload, correct? You never get this in FTP upload?
We've Vista here so we could try to reproduce the problem. Do you have an URL with the full applet running?
That is correct...it's in the HTTP POST only.

Our FTP Server is receiving just "/" as the path of the file so the uploaded file goes into the "root" folder for that FTP account (which is "/pub" on the server's drive) and not the "account" parameter that I set for the applet to use (which is "/FTPAppIn/[job#]" -- which on the FTP Server's drive is actually "/pub/FTPAppIn/[job#]").

And as I mentioned earlier, it only appears to happen when a Vista user uploads a file that is saved on their desktop (or in a folder on their desktop), and only when its the first file uploaded in that session.

I'll create a test account for you to access the pgm and email you the details to login and access it.

Thanks,
Cid

User avatar
support
Posts: 1503
Joined: Sun Jan 27, 2008 6:19 pm

Re: folderdepth still allowing deeper files

Post by support »

I've made a test with your account, I've sent the report by email.

frankdoss
Posts: 7
Joined: Sun Jul 25, 2010 4:52 pm

Re: folderdepth still allowing deeper files

Post by frankdoss »

Is there a real fix to this problem? Setting the value to one less than the target level count does not work for me. I don't want my users to transfer any subdirectories.

I have folderdepth set to 0, and it is searching one level. Not zero, not two, but one.

Everything else appears to be working well.

Thanks.

=====================================
applet_http_php.js is pasted below.
=====================================
<!--
var _info = navigator.userAgent;
var _ns = false;
var _ns6 = false;
var _ie = (_info.indexOf("MSIE") > 0 && _info.indexOf("Win") > 0 && _info.indexOf("Windows 3.1") < 0);
if (_info.indexOf("Opera") > 0) _ie = false;
var _ns = (navigator.appName.indexOf("Netscape") >= 0 && ((_info.indexOf("Win") > 0 && _info.indexOf("Win16") < 0) || (_info.indexOf("Sun") > 0) || (_info.indexOf("Linux") > 0) || (_info.indexOf("AIX") > 0) || (_info.indexOf("OS/2") > 0) || (_info.indexOf("IRIX") > 0)));
var _ns6 = ((_ns == true) && (_info.indexOf("Mozilla/5") >= 0));
if (_ie == true) {
document.writeln('<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" WIDTH="650" HEIGHT="250" NAME="fileupload" codebase="http://java.sun.com/update/1.4.2/jinsta ... on=1,4,0,0">');
}
else if (_ns == true && _ns6 == false) {
// BEGIN: Update parameters below for NETSCAPE 3.x and 4.x support.
document.write('<EMBED ');
document.write('type="application/x-java-applet;version=1.4" ');
document.write('CODE="jfileupload.upload.client.MApplet.class" ');
document.write('JAVA_CODEBASE="./" ');
document.write('ARCHIVE="/ftp/upload/lib/jfileupload.jar,/ftp/upload/lib/httpimpl.jar,/ftp/upload/lib/chttpclient.jar,/ftp/upload/lib/clogging.jar" ');
document.write('NAME="fileupload" ');
document.write('WIDTH="650" ');
document.write('HEIGHT="250" ');
document.write('url="http://vigil/ftp/process_upload.php">');
document.write('paramfile="uploadfile" ');
document.write('param1="todo" ');
document.write('value1="upload" ');
document.write('param2="errorheader" ');
document.write('value2="custommessage" ');
document.write('param3="relativefilename" ');
document.write('value3="true" ');
document.write('folderdepth="0" ');
document.write('mode="http" ');
document.write('scriptable=true ');
document.writeln('pluginspage="http://java.sun.com/products/plugin/ind ... "><NOEMBED>');
// END
}
else {
document.writeln('<APPLET CODE="jfileupload.upload.client.MApplet.class" JAVA_CODEBASE="./" ARCHIVE="/ftp/upload/lib/jfileupload.jar,/ftp/upload/lib/httpimpl.jar,/ftp/upload/lib/chttpclient.jar,/ftp/upload/lib/clogging.jar" WIDTH="650" HEIGHT="250" NAME="fileupload">');
}
// BEGIN: Update parameters below for INTERNET EXPLORER, FIREFOX, SAFARI, OPERA, MOZILLA, NETSCAPE 6+ support.
document.writeln('<PARAM NAME=CODE VALUE="jfileupload.upload.client.MApplet.class">');
document.writeln('<PARAM NAME=CODEBASE VALUE="./">');
document.writeln('<PARAM NAME=ARCHIVE VALUE="/ftp/upload/lib/jfileupload.jar,/ftp/upload/lib/httpimpl.jar,/ftp/upload/lib/chttpclient.jar,/ftp/upload/lib/clogging.jar">');
document.writeln('<PARAM NAME=NAME VALUE="fileupload">');
document.writeln('<PARAM NAME="type" VALUE="application/x-java-applet;version=1.4">');
document.writeln('<PARAM NAME="scriptable" VALUE="true">');
document.writeln('<PARAM NAME="url" VALUE="http://vigil/ftp/process_upload.php">');
document.writeln('<PARAM NAME="paramfile" VALUE="uploadfile">');
document.writeln('<PARAM NAME="param1" VALUE="todo">');
document.writeln('<PARAM NAME="value1" VALUE="upload">');
document.writeln('<PARAM NAME="param2" VALUE="errorheader">');
document.writeln('<PARAM NAME="value2" VALUE="custommessage">');
document.writeln('<PARAM NAME="param3" VALUE="relativefilename">');
document.writeln('<PARAM NAME="value3" VALUE="true">');
document.writeln('<PARAM NAME="folderdepth" VALUE="0">');
document.writeln('<PARAM NAME="mode" VALUE="http">');
// END
if (_ie == true) {
document.writeln('</OBJECT>');
}
else if (_ns == true && _ns6 == false) {
document.writeln('</NOEMBED></EMBED>');
}
else {
document.writeln('</APPLET>');
}
//-->

User avatar
support
Posts: 1503
Joined: Sun Jan 27, 2008 6:19 pm

Re: folderdepth still allowing deeper files

Post by support »

<PARAM NAME="folderdepth" VALUE="0"> should work. What about if you remove this parameter?

Post Reply