Skip to main content
D
DHL83
Known Participant
January 14, 2018
Answered

Flash Player 28 - flash.net.FileReference filename error when using "illegal" characters

  • January 14, 2018
  • 1 reply
  • 1420 views

I am maintaining a Flex app that allows for the user to upload files. When on Mac OS and trying to upload a file with an illegal Windows filesystem charachter, such as a "?" in the filename, for example: "amazing?image.jpg" Flash Player strips away the "?" and all characters after that. Flex reports that the filename the user selected is "amazing", resulting in a "not recognisable filetype error". Therefore my AS3 regex code, checking for illegal characters, is never triggered. This wasn't an issue in Flash Player 27.

It can be reproduced by trying to upload a .jpg-file with a "?" in the filename in the Flash upload sample on this page MultiPowUpload 3.4 multiple file uploader samples

    This topic has been closed for replies.
    Correct answer jeromiec83223024

    My test results *do* disagree with yours, in that this does not look like something we've broken recently.  It goes back at least nine months, and my intuition says that the inflection point is going to be a MacOS version and not a discrete Flash Player change. 

    First of all, thanks for the  answer. You are probably right about the issue going back, but I do seem to remember that I was able to trigger my code that would display an Alert if an illegal charachter was detected in the file name (doing a regex search on fileReference.name) back in November 2017. This code isn't triggered now because the illegal windows chars are stripped away before fileReference.name is filled with data.

    Anyway, is there a workaround to this? All I want is to do is prevent the users on MacOS/Linux from uploading files with chars that are unsupported in file names on Windows NTFS (/ ? < > \ : * | ").


    [correction] Yeah, you're right.  We upload the file as originally named.  It broke the directory listings on our IIS test server.  I totally forgot. 

    Do you require an extension on the filename?  Since you know that the string will be truncated in this instance, you're pretty much guaranteed to not have a valid extension on the file.  You could do a secondary check to ensure that the filename has an extension.  If it doesn't, you know that it's either failing the invalid character test, or it doesn't meet your naming requirements.  It's not the cleanest workaround, but it would probably solve the majority of these cases for you.  You can actually just check that FileReference.type is null in this instance.  Mac just gives you the extension back as a string.

    Honestly, you should probably validate the filename at the receiving script as well as the client.  It's not ideal, but you could reject the upload and return an error in the event that this sneaks through the client-side logic.

    I'd like to see us fix this, but realistically, it's going to be a couple months before it would land in a generally-available release.  If you have access to the server-side code, it might be worth just doing it as a stop-gap.

    1 reply

    jeromiec83223024
    jeromiec83223024
    Inspiring
    January 16, 2018

    As a workaround, you should be able to add a listener for the SELECT event on the FileReference, which would let you evaluate the filename before the user hits upload.

    D
    DHL83Author
    Known Participant
    January 18, 2018

    Unfortunately, that's already what I am doing:

    file.addEventListener(Event.SELECT, file_selected);

    where file is a FileReference and file_selected the event handler. file.name does not show the correct name if a special char is a part of the filename as described in my previous post. As stated, Flash Player strips away the special char (for example "?") and all characters after that.

    jeromiec83223024
    jeromiec83223024
    Inspiring
    January 19, 2018

    I wrote my own test this afternoon and was able to reproduce this behavior.  It seems to be specific to Mac.  I'm actually wondering if it's related to a MacOS change, but now I need to walk back through old MacOS builds.

    My test results *do* disagree with yours, in that this does not look like something we've broken recently.  It goes back at least nine months, and my intuition says that the inflection point is going to be a MacOS version and not a discrete Flash Player change. 


    I've opened a bug on it internally, but I'm not convinced at this point that there's a straightforward fix.  I was hoping to find a discrete changelist that precipitated the behavior, but that doesn't appear to be the case -- or at the very least, that change happened a long time ago.  I think it's far more likely that this is happening underneath us, but we'll need to continue to dig into it to determine the root cause.

    Here's what I'm seeing at this point.  I'm a little curious about how Linux handles this, but I suspect that it's very much tied to the underlying platform's file APIs.

    This is an interesting edge case, in that if you were talking about a URI, the '?' character denotes the beginning of the query parameter.  In that context, it makes sense that the rest of the string would be stripped, as it's not actually part of the resource name.  My guess is that the file is treated as a URI on this particular config.  I'm curious to see how it plays out.

    FAIL: Flash Player 28.0.0.137 on MacOS 10.12.6 with Chrome Version 63.0.3239.132 (Official Build) (64-bit)

    FAIL: Flash Player 28.0.0.137, 27.0.0.171, 26.0.0.151 on MacOS 10.12.6 with Firefox 57.0.4 (64-bit)

    PASS: Flash Player 28.0.0.137 on Win10 RS3 with Firefox 57.0.4 (32-bit)

    PASS: Flash Player 28.0.0.137 on Win10 RS3 with Chrome 63.0.3239.132 (Official Build) (64-bit)

    PASS: Flash Player 27.0.0.171on Win10 RS3 with IE 11

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices