Ticket #5534 (closed Bug: fixed)

Opened 4 years ago

Last modified 10 months ago

Uploading does not URL-encode the link at the end of the upload

Reported by: Saare Owned by:
Priority: Normal Milestone:
Component: General Version: 3.2.1
Keywords: Discussion Cc:

Description

Demonstration

  • Open the demo and open the Image dialog.
  • Go to 'Upload' tab and upload a file whose name contains characters that should be URL-encoded.
  • After the upload is finished, sometimes a JS is thrown and the dialog does not switch to the 'Image Info' tab. in that case, switch manually to this tab.
  • Take a look at the URL field. The characters that should be encoded (along with the space of the 'Public Folder' directory in the path) are not URL-encoded.

(For comparison, click on the 'Browse Server' button and select the file you have uploaded and notice that those characters are encoded)

Change History

comment:1 Changed 4 years ago by alfonsoml

  • Keywords Discussion added

CKEditor shouldn't do anything to the url sent by the upload script, so if anything requires escaping it must be done there or it would be impossible to use CKEditor with anything outside the typical setup of uploading files and return its path.

comment:2 Changed 4 years ago by Saare

The problem here is, as I said, when the URL after the upload is not encoded, a JS error is thrown and the dialog does not switch back to the Info tab.
Actually, I've just noticed that the selected file name is for some reason not fully encoded too (tested with /userfiles/images/Public%20Folder/%D7%A2%D7%A2%25%25%23%23@@55(1).png), and a JS error is thrown when clicking OK to insert the image, so encoding the URL might be the only way of solving this bug.

comment:3 Changed 4 years ago by alfonsoml

#5527 is an example of why the encoding can't be done at the js side because it lacks the context to understand what are the parts of the url and how each part must be encoded.

As long as the "file name" is a valid string, no js errors should happen and that value should be shown in the URL, without need to do any extra encoding.

comment:4 Changed 4 years ago by Saare

I see what you mean, so in that case another solution should be fonud to the bug i presented, because there is no reason a file named '/userfiles/images/Public%20Folder/%D7%A2%D7%A2%25%25%23%23@@55(1).png' will trigger an error.
Anyhow, CKFinder might have a related problem, because it yields inconsistent result.

comment:5 Changed 10 months ago by j.swiderski

  • Status changed from new to closed
  • Resolution set to fixed

I have tried reproducing this in current CKFinder 2.3.1 but no error occurred.

If I remember correctly - There was some research and work (concerning encoding and server settings) made that resolved issues with files containing non-iso or 'must encode' characters in their names.

I'm closing this issue as fixed.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy