Thanks for the tip, Jim.

My only concern would be whether or not the user
would understand that the filename above the blank
field would be what "will be" (from their perspective) uploaded.

Also, would I have to use a UUID and temp dir?  Could I not
just go ahead and upload the file, insert the file info into the database,
and the file itself into the desired directory, then, if the user
changes the file, just delete the first one, then upload the second?

Another concern...what if the user decided not to use a file at all?
I guess I would have to provide a checkbox for the user to select
to "Do not use currently selected file"  in order to delete the
previously uploaded file... ?

Rick

-----Original Message-----
From: Jim [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 6:14 AM
To: CF-Talk
Subject: Re: Any reason why a file field can be submitted back to the
page it's on?


If I have understood correctly, you simply dont want the user to have to
select and upload the file again?

Heres what I do in this situation:

The file gets uploaded anyway.
Give it a unique name e.g. use a UUID, and put it in a temp dir.
Store the name of the temp file in a hidden form variable.
Display the user friendly name of the file (the one from the form field)
above the file field.

So you have in the form:

Your current file:  something.jpg
Upload new file: [                       ][Browse...]

This means the user does not have to select / upload again, just because
there is a server side validation problem with another field.

When the user completes the form correctly, you have the name of the
file in the temp dir from the hidden form field.
You can do whatever you need from there.


Rick Faircloth wrote:
> So, to enable the kind of functionality I'm proposing would mean
> to provide complete open access to all files on a site visitor's system?
>
> If that's the case, then I understand why the W3C wrote it out of the
> specs.
>
> However, since Javascript and Active X have been suggested as
> alternatives to accomplish my programming goals, how can Javascript
> or Active X accomplish this without creating the vulnerability?
> (Although I haven't used it in programming, I know Active X has a
> reputation for creating vulnerabilities, and I guess Javascript, too)
>
> Rick
>
> -----Original Message-----
> From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 25, 2006 5:01 AM
> To: CF-Talk
> Subject: Re: Any reason why a file field can be submitted back to the
> page it's on?
>
>
> Rick Faircloth wrote:
>
>>> any malicious programmer could exploit it in their own web pages
>>>
>> You mean that a malicious programmer could be hired by someone
>> to code web pages for them and then take advantage of the person
>> hiring them.  Am I understanding?
>>
>
> No.
>
>
>
>> But, like I said in another post...I'm sure I don't understand all the
>> security issues surrounding the decision, so I won't pass final judgment
>> on the W3C without better understanding...
>>
>
> Let's say I rip out this security from Firefox and compile a
> Firefox version specially for you. You start using it. Everybody
> starts using it. You visit one of my websites and through some
> slick, hidden HTML I decide that you should upload your Filezilla
> profile to my website. Your browser, without this security,
> uploads the asked file to me. I now have a copy of all your FTP
> passwords.
>
> Jochem
>
>
>
>



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:241433
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to