You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I create a web-form with a custom FilePicker INPUT Buttion type=FILE, a user may click that button, choose a file from their hard drive (they know where the file is, they have the entire PATH.
Since this is a FORM where the user may add more than one document, I do NOT want to $_POST/Submit the form yet. But at the same time, I want to put an icon next to the file button (part of the customer behavior) that they can click on to view the file (a PDF for example).
However, since Javascript only returns: C:\fakepath\gs300_datasheet.pdf
This is absurd and ridiculous. No security violation occurs here because we're not interested in the back-end. Once the document is $_POSTed, I get the full path anyway! But since I'm trying to allow the user to attach several documents in the form, I cannot get the path, which the user knows, and thus cannot display the PDF (or other document) to them pre-$_POST.
This affects every browser implementation out there and is the greatest bane to every javascript/ECMAscript developer. Look at the forums filled with people trying to figure this out.
This has GOT TO BE FIXED. All the Standard has done is this case, is to create a security block when there is no security issue to begin with for reasons stated above.
At present neither ECMA, nor anybody else can given me 1 good reason or example as to how preventing me from getting a file path that the user already knows about is a security violation when all I want to do is display the document pre-$_POST.
The text was updated successfully, but these errors were encountered:
The end user might have sensitive information (such as their name or username) as part of the actual path to the file. This is not information we wish to divulge to websites.
It seems reasonable to more clearly state this in the standard as this might not be obvious to everyone indeed.
annevk
changed the title
Incorrect Security Bug for GetFile INPUT Button (custom)
Clarify why <input type=file> hides the real path
Feb 27, 2025
Per https://whatwg.org/code-of-conduct, we'll ban the above user from commenting on WHATWG repositories for 30 days. If they continue with abusive behavior after that, the ban will become permanent.
What is the issue with the HTML Standard?
If I create a web-form with a custom FilePicker INPUT Buttion type=FILE, a user may click that button, choose a file from their hard drive (they know where the file is, they have the entire PATH.
Since this is a FORM where the user may add more than one document, I do NOT want to $_POST/Submit the form yet. But at the same time, I want to put an icon next to the file button (part of the customer behavior) that they can click on to view the file (a PDF for example).
However, since Javascript only returns: C:\fakepath\gs300_datasheet.pdf
This is absurd and ridiculous. No security violation occurs here because we're not interested in the back-end. Once the document is $_POSTed, I get the full path anyway! But since I'm trying to allow the user to attach several documents in the form, I cannot get the path, which the user knows, and thus cannot display the PDF (or other document) to them pre-$_POST.
This affects every browser implementation out there and is the greatest bane to every javascript/ECMAscript developer. Look at the forums filled with people trying to figure this out.
This has GOT TO BE FIXED. All the Standard has done is this case, is to create a security block when there is no security issue to begin with for reasons stated above.
At present neither ECMA, nor anybody else can given me 1 good reason or example as to how preventing me from getting a file path that the user already knows about is a security violation when all I want to do is display the document pre-$_POST.
The text was updated successfully, but these errors were encountered: