By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,335 Members | 2,718 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,335 IT Pros & Developers. It's quick & easy.

Prevent a Paste of a Filename in an Input Type=File

P: n/a
I rarely crosspost, but this affects both ASP and Javascript

REALLY odd bug that I ran across in ASP 3.0. I have an input type of
file, user clicks browse, then places his cursor in the filename, puts
a space at the end of the file, and uploads it. Web server doesn't
translate the MIME type of document properly because it doesn't end
with a valid extension, yet the file itself uploads successfully. I'm
using SAFileUP for my uploading component.

So I now return a FALSE in an ONKEYPRESS event, which prevents the
user from entering a space at the end of the file (why he does this is
beyond me, but I'm trying to idiot proof this thing).

Problem is, the ONKEYPRESS doesn't prevent a Paste of a string into
the field, so it's still technically possible to munge the filename.
Blurring the control on a focus or setting it to disabled doesn't work
because it makes the Browse button unfunctional.

Platform: i.e.6.

Any ideas?

Feb 8 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
input fields are **READ ONLY** by javascript. That is you can look but
you can not in any way modify the contents or alter the behavior. What
you can do is to do an onSubmit event in your form and check the file
name, if there is anything you don't like about it (trailing spaces for
instance) you can alert the user and disallow the submission.

That's the best you can hope for. Sorry.


Larry Bud wrote:
I rarely crosspost, but this affects both ASP and Javascript

REALLY odd bug that I ran across in ASP 3.0. I have an input type of
file, user clicks browse, then places his cursor in the filename, puts
a space at the end of the file, and uploads it. Web server doesn't
translate the MIME type of document properly because it doesn't end
with a valid extension, yet the file itself uploads successfully. I'm
using SAFileUP for my uploading component.

So I now return a FALSE in an ONKEYPRESS event, which prevents the
user from entering a space at the end of the file (why he does this is
beyond me, but I'm trying to idiot proof this thing).

Problem is, the ONKEYPRESS doesn't prevent a Paste of a string into
the field, so it's still technically possible to munge the filename.
Blurring the control on a focus or setting it to disabled doesn't work
because it makes the Browse button unfunctional.

Platform: i.e.6.

Any ideas?

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA
Feb 8 '07 #2

P: n/a
I rarely crosspost, but this affects both ASP and Javascript
>
REALLY odd bug that I ran across in ASP 3.0. I have an input type of
file, user clicks browse, then places his cursor in the filename, puts
a space at the end of the file, and uploads it. Web server doesn't
translate the MIME type of document properly because it doesn't end
with a valid extension, yet the file itself uploads successfully. I'm
using SAFileUP for my uploading component.
So I now return a FALSE in an ONKEYPRESS event, which prevents the
user from entering a space at the end of the file (why he does this is
beyond me, but I'm trying to idiot proof this thing).
Problem is, the ONKEYPRESS doesn't prevent a Paste of a string into
the field, so it's still technically possible to munge the filename.
Blurring the control on a focus or setting it to disabled doesn't work
because it makes the Browse button unfunctional.
On Feb 8, 12:54 pm, pcx99 <x...@x.comwrote:
input fields are **READ ONLY** by javascript. That is you can look but
you can not in any way modify the contents or alter the behavior. What
you can do is to do an onSubmit event in your form and check the file
name, if there is anything you don't like about it (trailing spaces for
instance) you can alert the user and disallow the submission.

That's the best you can hope for. Sorry.
Yeah, I realize it's read only, I was just hoping there was a way to
prevent a paste.

But that's what I'm doing, I'm checking for a validly formed filename.
Feb 8 '07 #3

P: n/a
pcx99 wrote on 08 feb 2007 in microsoft.public.inetserver.asp.general:
input fields are **READ ONLY** by javascript. That is you can look but
you can not in any way modify the contents or alter the behavior.
That so? Methinks not!

<input name='q' id='q' value='first'>
<script type='text/javascript'>
var q = document.getElementById('q')
alert(q.value) // read value
q.value = 'second' // overwrite value
</script>

Only <input type='file'values unaccessable by js, both read and write!

<input name='q' id='q' value='first' type='file'>
<script type='text/javascript'>
var q = document.getElementById('q')
alert(q.value) // blank
q.value = 'second' // no effect
</script>
Larry Bud wrote:
>I rarely crosspost, but this affects both ASP and Javascript
Many ASP scripting is written in J[ava]script! ;-)

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 8 '07 #4

P: n/a
Evertjan. wrote:
pcx99 wrote on 08 feb 2007 in microsoft.public.inetserver.asp.general:
>input fields are **READ ONLY** by javascript. That is you can look
but you can not in any way modify the contents or alter the behavior.

That so? Methinks not!
He should have said "input fields whose type is "file" ... "

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Feb 8 '07 #5

P: n/a
Bob Barrows [MVP] wrote on 08 feb 2007 in
microsoft.public.inetserver.asp.general:
Evertjan. wrote:
>pcx99 wrote on 08 feb 2007 in microsoft.public.inetserver.asp.general:
>>input fields are **READ ONLY** by javascript. That is you can look
but you can not in any way modify the contents or alter the behavior.

That so? Methinks not!

He should have said "input fields whose type is "file" ... "
Even so, as I showed, they are NOT read only, Bob,
as they cannot EVEN be read by clientside javascript.
They, the type-file-input-values, are simply inaccessable.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 8 '07 #6

P: n/a
Clientside javascript has no problems reading the contents of an input
of type file. It will crash your script with a security error if you
attempt to use javascript to change the contents though. The newer
browsers will show only the file name and not the full path (IE7
notably), perhaps the path filters threw out your input as invalid
before the display. Regardless...

<form>
<input type="file" id="ff">
</form>

<button onClick="alert(document.getElementById('ff').value )">Click Me to
read</button>

Will quite merrily show you the contents of the input field provided
there is actually something there.

And Bob is quite right, I should have specified type=file, however it
really didn't occur to me that given the question it would actually need
to be stated. Sometimes the lawyerball in these forums can be quite
maddening.

Evertjan. wrote:
Bob Barrows [MVP] wrote on 08 feb 2007 in
microsoft.public.inetserver.asp.general:
>Evertjan. wrote:
>>pcx99 wrote on 08 feb 2007 in microsoft.public.inetserver.asp.general:

input fields are **READ ONLY** by javascript. That is you can look
but you can not in any way modify the contents or alter the behavior.
That so? Methinks not!
He should have said "input fields whose type is "file" ... "

Even so, as I showed, they are NOT read only, Bob,
as they cannot EVEN be read by clientside javascript.
They, the type-file-input-values, are simply inaccessable.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA
Feb 8 '07 #7

P: n/a
pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:

[Please do not toppost on usenet]
Clientside javascript has no problems reading the contents of an input
of type file. It will crash your script with a security error if you
attempt to use javascript to change the contents though. The newer
browsers will show only the file name and not the full path (IE7
notably), perhaps the path filters threw out your input as invalid
before the display. Regardless...

<form>
<input type="file" id="ff">
</form>

<button onClick="alert(document.getElementById('ff').value )">Click Me
to read</button>
Will quite merrily show you the contents of the input field provided
there is actually something there.
You are right, I did a test that showed otherwise,
[by specifying value='qwerty', but that is in itself faulty]
And Bob is quite right, I should have specified type=file, however it
really didn't occur to me that given the question it would actually
need to be stated.
No, my argument was about the "read only", not the specification per se.
Sometimes the lawyerball in these forums can be quite
maddening.
'lawyerball' what is that? If you want to say something please do not
use local slang.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 9 '07 #8

P: n/a
Evertjan. wrote:
pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:

[Please do not toppost on usenet]
That is a definition of lawyerball.
'lawyerball' what is that? If you want to say something please do not
use local slang.
As is this.

Consider it thus: Quibbling over inconsequential semantics and requiring
every last word to be strictly, legally defined to accommodate anal
retentive people who are unable to read things in context.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA
Feb 9 '07 #9

P: n/a
pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:
Evertjan. wrote:
>pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:

[Please do not toppost on usenet]

That is a definition of lawyerball.
You don't even seem to know the definition of definition.
>'lawyerball' what is that? If you want to say something please do not
use local slang.

As is this.

Consider it thus: Quibbling over inconsequential semantics and requiring
every last word to be strictly, legally defined to accommodate anal
retentive people who are unable to read things in context.
If you are happy arguing about that, so be it.
You must be new on usenet,
expecting to make your own netiquette and
disregarding that these are two international NGs.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Feb 9 '07 #10

P: n/a

"Evertjan." <ex**************@interxnl.netwrote in message
news:Xn********************@194.109.133.242...
pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:
Evertjan. wrote:
pcx99 wrote on 09 feb 2007 in microsoft.public.inetserver.asp.general:

[Please do not toppost on usenet]
That is a definition of lawyerball.

You don't even seem to know the definition of definition.
'lawyerball' what is that? If you want to say something please do not
use local slang.
As is this.

Consider it thus: Quibbling over inconsequential semantics and requiring
every last word to be strictly, legally defined to accommodate anal
retentive people who are unable to read things in context.

If you are happy arguing about that, so be it.
You must be new on usenet,
Yeah those us who have been around these news groups have just given up
arguing with you about it ;)
Feb 9 '07 #11

P: n/a
pcx99 wrote:
The newer browsers will show only the file name and not the
full path (IE7 notably), perhaps the path filters threw out
your input as invalid before the display.
For what it's worth, IE7 still sends the full path with the form submission,
regardless of what it displays.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Feb 9 '07 #12

P: n/a
Dave Anderson wrote:
pcx99 wrote:
>The newer browsers will show only the file name and not the
full path (IE7 notably), perhaps the path filters threw out
your input as invalid before the display.

For what it's worth, IE7 still sends the full path with the form submission,
regardless of what it displays.

Yea that is hilariously funny, they go to extreme lengths (and break
many existing apps) to mask the full path in the browser and then send
the full path to the server. This ranks right up there with them
breaking the prompt command.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA
Feb 9 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.