The issue was that before webnative version 0.24, permissions paths were always implicitly converted to directory paths (because you could only permission directory paths). If new apps now try to use permissions for e.g. fs: { publicPaths: ["Apps"] } (webnative v.0.23 syntax), that will get turned into the query param publicPath=Apps, which doesn't give an indication that this is supposed to be a directory, not a file.
There's also something else in here that we should fix I think: If you try to permission e.g. private/Apps as a file, but it already exists as a directory, what should the auth lobby do? I think at the moment it'll just share the read key for the directory instead of for the file. But that might confuse webnative, and generally isn't expected.
Before:
After:
The issue was that before webnative version 0.24, permissions paths were always implicitly converted to directory paths (because you could only permission directory paths). If new apps now try to use permissions for e.g.
fs: { publicPaths: ["Apps"] }(webnative v.0.23 syntax), that will get turned into the query parampublicPath=Apps, which doesn't give an indication that this is supposed to be a directory, not a file.There's also something else in here that we should fix I think: If you try to permission e.g.
private/Appsas a file, but it already exists as a directory, what should the auth lobby do? I think at the moment it'll just share the read key for the directory instead of for the file. But that might confuse webnative, and generally isn't expected.