Pre-filling FileField Values

Is there some way to pre-fill a filefield value? I'm trying this:    <cfloop from="1" to="#filenamelist.recordcount#" index="i">         <cfoutput>#i#</cfoutput><br>         <cfoutput>filenameList.recordcount = #filenameList.recordcount#</cfoutput><br>         <input name="<cfoutput>#i#</cfoutput>" type="file" value="<cfoutput>#filenameList.name[i]#</cfoutput>"><br>    </cfloop> And it gives me the correctly rendered HTML:    <input name="1" type="file" value="E:\UploadDirectory\2008_0819_sav_mlxchange_image.jpg"><br>       <input name="2" type="file" value="E:\UploadDirectory\2008_0819_sav_mlxchange_image_data_and_photo_download.jpg"><br>       <input name="3" type="file" value="E:\UploadDirectory\2008_0819_sav_mlxchange_image_data_download.jpg"><br> But when the filefields are displayed in the browser, the filefields are empty. Is there some way to get the E:\UploadDirectory\2008_0819_sav_mlxchange_image.jpg to show up in the dynamically created filefields? Thanks, Rick

No.  It's a security hole.  Imagine being able to pre-fill it with C:\my documents\sensitive file.doc and then hiding the form field so they never even knew about it. You could upload any file you wanted from your user and all they would need to do was submit the form.  Well, heck, you can automatically submit forms with JavaScript anyway... ~Brad > Is there some way to pre-fill a filefield value?

>>and all they would need to do was submit the form. Not even, this could be done in an onload event ;-)

I would be interested in your use case for this. As everyone has already pointed out this is a huge security risk but even from a user standpoint it doesn't make sense to me why you would want to do this? Thank You Dan Vega danvega@gmail.com http://www.danvega.org On Thu, Aug 28, 2008 at 1:46 PM, Claude Schneegans < schneegans@internetique.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

Dan Vega wrote: > I would be interested in your use case for this. As everyone has already > pointed out this is a huge security risk but even from a user standpoint it > doesn't make sense to me why you would want to do this? I've run into this request when working with corporate web applications.  The process usually involves some regualar data upload by a user where the file follows a specific format including names.  The idea being why should the poor overworked employee be bothered with navigating the file system and selecting the file when it is the same ever day|week|month.  "Couldn't they just click a button or something?" I then reply, 'No they can't if you want this to be a quick and cheap application using a browser.  Want to pay for me to learn AIR and we will discuss this/'  At least that is how the reply is worded in my head.

Actually, I was just responding to someone's request on the cf-newbie list for a way to upload an entire directory at once. I thought perhaps there was a way to auto-fill with a cfdirectory-generated list and corresponding fields for each file that would be pre-filled, then all the user would have to do is hit the submit button to upload all the files in the fields.  Just trying to avoid each file being selected individually for the user. However, I could certainly use this feature in my real estate apps. Sometimes clients want to load 20 photos or more of a property and they complain about having to select each photo individually. I've used javascript to create an "Add another file upload field" function that clones the filefields and prevents the user from having to submit one file at a time, but they still have to select each file using "Browse". At this point, I don't see how pre-filling the fields with values that the user is placing there is a security risk.  I'm sure in some way that I'm not familiar with the function could be abused. It just seems like with some limitations placed on a "group file upload", such as no hidden fields allowed, etc, that the function could be brought into use without security risks.  The name of the file (which is often obscured in the filefields without working to view the filename) could be placed above the filefields when they are generated to assure the user of what's being uploaded. There are javascript solutions for this, so why can't CF have one that doesn't pose a security risk, if the javascript solutions don't? Rick ----- Excess quoted text cut - see Original Post for more -----

> I thought perhaps there was a way to auto-fill with a > cfdirectory-generated list and corresponding fields for > each file that would be pre-filled, then all the user would First, CFDIRECTORY only has access to the files and directories on the server, not the client, so you wouldn't be able to "list" the user's folders and pre-populate the fields anyway. > At this point, I don't see how pre-filling the fields with values > that the user is placing there is a security risk.  I'm sure in some > way that I'm not familiar with the function could be abused. Ok, imaging that there is a widely used accounting program that stores its data file in the same location on every install.  Now, imagine a malicious web author sending spam for free Paris Hilton pictures.  The unsuspecting user visits the page, but it's asking for their age before it will let them through.  No problem!  Here's my age, click submit, and WHAM, they now have your accounting database.  How?  Because they put a file upload field with the path to your database pre-populated.  Maybe the field was hidden, covered with an image, or re-positioned off screen so the user didn't see it.  Whatever the case, the browser won't let you do that to prevent this scenario. > It just seems like with some limitations placed on a "group file upload", > such as no hidden fields allowed, etc, that the function could be > brought into use without security risks.  The name of the file (which > is often obscured in the filefields without working to view the filename) > could be placed above the filefields when they are generated to assure > the user of what's being uploaded. That's one of the faulty assumptions; that user's check for these sorts of things before they click submit.  How many years did it take to train people to look for the lock icon when making a purchase?  The browser vendors had to start changing the color of the address bar to get people to notice! > There are javascript solutions for this, so why can't CF have one > that doesn't pose a security risk, if the javascript solutions don't? I think the JS method someone mentioned exploited a bug in IE to get around that, and said bug has since been patched so even that won't work anymore. -Justin Scott

>There are javascript solutions for this, so why can't CF have one >that doesn't pose a security risk, if the javascript solutions don't? > >Rick It should be pointed out that CF is not involved in this limitation at all.  If you want to make a case for change it would need to be made with the HTTP|HTML standard boards and the browser makers who follow their recommendations.

This issues just sounds like it could be addressed by placing limitations on what type of files are acceptable in the upload.  Such as with cffile... I don't really know. ----- Excess quoted text cut - see Original Post for more ----- case > for change it would need to be made with the HTTP|HTML standard boards and the browser makers who follow > their recommendations.

Rick Faircloth wrote: > This issues just sounds like it could be addressed > by placing limitations on what type of files are acceptable > in the upload.  Such as with cffile... I don't really know. But the point is that <cffile...> would happily accept anything right now.  ColdFusion does not care and is *NOT* limiting you here. Your BROWSER is limiting you.  Adobe could put all the limits we want!   But until the makers of Internet Explorer and FireFox and Opera and all the others get together and decide to go against the recommendations created by the HTTP and HTML standards or these standards are changed, it will not do any good at all. And how would Adobe fixing <cffile...> to be secure protect uses for unscrupulous programmers using ASP, .NET, PHP, PERL, CGI, JAVA, C++ and anything else that could be used to program an page. Especially since the security whole we are talking about does not even require an Application processor.  I could hand code a file stealing form in Notepad and save it to a server and then manually collect all the files from the Web Server if this where allowed.

Yes, getting the basic standards which restrict functionality would be another whole game... ----- Excess quoted text cut - see Original Post for more -----

The bottom line is that you cannot use JavaScript to set the value of a file field. You just can't do it. The browser makers went out of their way to make sure that this is impossible due to the devastating security issues that would result if it were allowed. There is absolutely no way to insert a value into a file input element using JavaScript. The only way a value can be put in there is a result of the user choosing a file in the file selection dialog box. All the multi-upload JavaScript tricks are doing is creating separate hidden file input fields, but the user still has to explicitly choose a file value to put into it. Regards, Brian On Thu, Aug 28, 2008 at 5:03 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: > This issues just sounds like it could be addressed > by placing limitations on what type of files are acceptable > in the upload.  Such as with cffile... I don't really know. > >

> the user still has to explicitly choose a file value to put into it And that's good...the user should know exactly what they're uploading and be able to control that. However, if I want to take responsibility to designate an entire folder of files for upload, I should be able to do that, too.  Not just one file at a time, but choose the folder and all its contents. Why not? ----- Excess quoted text cut - see Original Post for more -----

> However, if I want to take responsibility to designate an entire folder > of files for upload, I should be able to do that, too.  Not just one file > at a time, but choose the folder and all its contents. > > Why not? I think you're completely missing the whole security issue that would be created if they allowed that.  You see it as functionality to make life easier for the users.  The hackers see it as a golden opportunity to do a drive-by upload of your entire hard drive.  Fortunately the people who design the protocols and standards have the ability to recognize this, and I, for one, am thankful for that. -Justin Scott

> The hackers see it as a golden opportunity to do > a drive-by upload of your entire hard drive. But why is there more risk for a user to upload a single directory, and *only* a single directory of their choosing than to upload single files.  Is it just to protect them from themselves?  With the limitation of the function to one directory without recursion, I don't see how those poses risk to a user's or my server's hard drive.  No recursion and limitation on file types... How would the "one folder" method be more risky than the "one file" method? And I'm asking because I really want to understand, not because I think I know what's better... ----- Excess quoted text cut - see Original Post for more -----

> How would the "one folder" method be more risky than the "one > file" method? If they're still clicking and selecting then it isn't more risk per se, but creates issues in usability for the user.  If they're not careful they could theoretically upload their entire My Documents folder without realizing it when they intended to send one file. -Justin Scott

Well, I just set up something that to say: "You're about to upload xyz (file or folder). Are you sure this is what you want to do?" Yes   No Of course I don't want all that on my server, so maybe I would have to limit the name of the folder their uploading to a specific name. <cfdirectory action="upload" recursive="no" specifyDirectory="yes" directoryName="Photos" dataLimit="yes" DataSizeLimit="100" (MB) MaxNumberofFiles="100" UseThread="yes" ThreadName="PhotoUpload"> Whatever...I'm tired...FTP or having the client zip their files sounds good... Looks like it nobler in the mind to suffer... ----- Excess quoted text cut - see Original Post for more -----

>>If they're still clicking and selecting then it isn't more risk per se, but creates issues in usability for the user.  If they're not careful they could theoretically upload their entire My Documents folder without realizing it when they intended to send one file. Right, but the browser could calculate the total length of data, the number of files, estimate the time required, and ask for a confirmation. The maximum size allowed by the server to transfer could also be part of the protocol. After all, one could also delete all his files in his system, this is nor a reason to force him to delete files one at a time. Taking all users for idiots is not any better than limiting facilities for all in case one makes an error..

> Right, but the browser could calculate the total length ... Could, yes, but I don't expect to see an "upload a folder" feature added to HTTP or the browsers as a standard any time soon. > After all, one could also delete all his files in his system, this is > nor a reason to force him to delete files one at a time. There's a big difference between accidentally deleting files and accidentally sending them to a server somewhere.  In any case, this is getting to be off-topic and would be better taken to a standards body if anyone really wants to pursue the debate. -Justin Scott

On Thu, Aug 28, 2008 at 7:03 PM, Rick Faircloth <Rick@whitestonemedia.com>wrote: ----- Excess quoted text cut - see Original Post for more ----- Because that isn't what HTTP was ever designed to do. They made a whole protocol just to handle this: FTP. I'm somewhat confused about your point now. It's clear that what you're attempting to do is simply not possible using only a web broswer and a form. There are other avenues such as AIR, ActiveX, Java applets, or FTP that will do this. But unless you start mailing standards bodies and browser makers with enhancement requests, this avenue is closed. I can tell you that it makes functional testing a pain, because if you want to use something like Selenium to test a page that does a file upload, you're out of luck. Annoying? Maybe in some cases. Likely to change? Unlikely to the point of being moot, I'm afraid. Regards, Brian

I hear what you're saying.  I just like to rail against the limitations some. "Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous misfortune, or to take arms against a sea of troubles and by opposing end them..." ----- Excess quoted text cut - see Original Post for more -----

>>Because that isn't what HTTP was ever designed to do. They made a whole protocol just to handle this: FTP. I think this kind of argument is completely obsolete now. Both HTTP and FTP were designed to allow exchanges between computers made by computer scientists. Now, at least for HTTP, their role has been extended to low end users. As such, there is no reason the protocols could not be extended too.

Rick Faircloth wrote: > However, if I want to take responsibility to designate an entire folder > of files for upload, I should be able to do that, too.  Not just one file > at a time, but choose the folder and all its contents. With the extensions of RFC 2388 the HTTP protocol is perfectly capable of allowing a user-agent to upload an entire directory in one HTTP post. The choice not to implement that functionality in browsers is one made by browser vendors. Any inquiries as to why they made that choice should be directed to them. Jochem

I believe the Zip functionality that was suggested to the CFnewbie poster would be an ideal solution for your 20 photos. You can instruct the client to zip all of the photos into a zip file and then upload using the form. You can check to see if it is a .zip file, if it is, you can unzip it to your app directory and then loop over the image files inside to process them into your site.  (if you resize/thumbnail/etc) Good luck, William ----- Excess quoted text cut - see Original Post for more -----

Thanks for the suggestion, William.  I'll keep that in my notes as a solution next time I'm confronted with that issue. Rick > I believe the Zip functionality that was suggested to the CFnewbie poster would be an ideal solution for > your 20 photos. > > You can instruct the client to zip all of the photos into a zip file and then upload using the form. > > You can check to see if it is a .zip file, if it is, you can unzip it to your app directory and then ----- Excess quoted text cut - see Original Post for more -----

> process them into your site.  (if you resize/thumbnail/etc) Oh, yes, definitely.  The image processing of CF 8 is the main reason why I upgraded from CF 4.5!  I was soooo glad to see those capabilities! > I believe the Zip functionality that was suggested to the CFnewbie poster would be an ideal solution for > your 20 photos. > > You can instruct the client to zip all of the photos into a zip file and then upload using the form. > > You can check to see if it is a .zip file, if it is, you can unzip it to your app directory and then ----- Excess quoted text cut - see Original Post for more -----

>>Sometimes clients want to load 20 photos or more of a property and they complain about having to select each photo individually. Exact, one should be able to upload "every thing like *.jpg in a directory, or select several files in it. I've implemented another solution were clients can send all their images in one zip file, and I unzip it on the server. Of course, there is no gain in size, and users must be able to zip files, but at least for this application, it doesn't look like it is asking too much ;-)

> but at least for this application, it doesn't look like it > is asking too much ;-) Ha! Claude!  Are you kidding!  I'll bet if I asked all of my clients to zip up a folder of folders, only 10% would know how to do it without in-depth instruction... ----- Excess quoted text cut - see Original Post for more -----

> Ha! Claude!  Are you kidding!  I'll bet if I asked all of my > clients to zip up a folder of folders, only 10% would know > how to do it without in-depth instruction... For those types I generally just deploy an FTP account and craft a URL that they can click on such as: ftp://user:pass@my.ftpserver.com/ Then they can just drag and drop the files into the Explorer window and it uploads them to the server.  Depending on the application a process can either run periodically to sweep the files in and process them into a general file/image library, or they can click the "import images" button when adding a record and it will go pull in anything in the upload folder. Gets around the whole "click and select each file individually" issue, the ZIP issue, AND the HTTP timeout issue all at once.  If you craft your user interface well then it becomes easy for the users. -Justin Scott

Sounds like a good idea! ----- Excess quoted text cut - see Original Post for more -----