Validating input of file:/ URLs


#1

I’m missing a validation-step in URL's interface to retrieving local files. Namely calling URL::isLocalFile() can return true when a subsequent call to URL::getLocalFile() can hit an assertion. This can easily be reproduced by passing a Unix style path in an URL on Windows e.g. file:///Path/To/Absolute/File.
Could we have a method in URL to validate that constructing a File object from it is legal or alternatively expose a method similar to URL::fileFromFileSchemeURL() that returns an unescaped and processed path encoded in the URL so we can perform this validation our self?

Also an addition to the documentation warning about a possible second assertion would be welcome.


#2

Maybe this is all too complicated and returning an invalid File object would be a good start already.


#3

Well the docs for isLocalFile just say “Returns true if this URL refers to a local file.”, there’s no mention of any verification…

Where are these paths coming from and what are you doing with them?

Doing File f ("/Path/To/Absolute/File"); will assert on Windows, so perhaps we should also assert on File f ("file:///Path/To/Absolute/File");.


#4

The URL is coming from our kit files. Which can be saved in mac and reused in windows. I just don’t think that hitting an assertion is a graceful thing to do in that case. Especially since there is no good way to validate selfs. At the moment i just copied code from URL::fileFromFileSchemeURL() and do validation on my own.


#5

I think asserting is sensible as it’s indicating a reasonably significant problem - there’s no hope of having absolute paths working across platforms.

In a release build the URL will simply resolve to a file path that doesn’t exist.


#6

Ok. Can we have access to a version of URL::pathFromFileSchemeURL() then that returns the path as string with all the decoding done so we can test that our selfs?
Btw: some sort of static bool File::isPathLegal(const String &path) would be helpful too


#7

I agree some kind of isPathLegal would be useful, but it doesn’t sound like a good solution to your problem. If you are translating files paths across systems then you would need to have the files stored in some kind of canonical place, like userApplicationDataDirectory, in which case you should just store the components of the relative path required. If you really need to store absolute paths then you should also store some kind of machine ID which they correspond to, otherwise there’s a (small) risk of opening an unexpected file that happens to have the same name.


#8

There is something to what you say and i shall consider storing this exact path relative. But i’d still want to have an absolute path stored somewhere as a fallback. And to be honest i’d probably still try to open that file even if the machine id mismatches just because it is entirely possible that a user migrates their projects to a new machine.
These questions are all quite tricky and it is hard to find a good balance between portability, security etc.