uploading images with a hash sign fails, access denied

[Plaster]

https://files.facepunch.com/forum/upload/483/3139fe4b-2b96-43b9-886c-45342c7ea6fa/hash#.PNG

probably known, maybe not. there are probably many more symbols that could cause this.

https://files.facepunch.com/forum/upload/483/82c65f9a-5142-4ae1-9042-1dec9d9b3757/hash#.PNG

doesn't mater where the symbol is

https://files.facepunch.com/forum/upload/483/1eb168a6-78c6-49ea-a33d-3b341ce15df7/hash# - Copy.PNG

this one's without one

https://files.facepunch.com/forum/upload/483/9d8c63d5-e8f9-4d31-b850-4f2b84e1554d/hash.PNG

[Alice]

This is probably a matter of Facepunch accepting images with filenames that browsers consider invalid. Since hashes are used to jump to an anchor on a page, the browser will get confused so Facepunch shouldn't even accept files with a hash in the name.

[Scratch]

This is a problem with azure. I've had this issue myself when maintaining ShareX for blob storage.

I've reported the issue, but I'm pretty sure the engineers are not aware if it

[Scratch]

Additional follow up, remembered getting asked to test this from the portal.
This error also does occur from the Microsoft's native file uploader.
So the implementation of the file uploader is all correct. Just typical Microsoft platform fuckery

[Alice]

Interestingly I ran into a similar issue in a (Javascript) project of mine the other day but after simply opening the image that was causing issues for me by dragging and dropping it into Firefox I realize it was a url encoding issue. The hash breaks the url but if it's encoded properly (%23) then it works.

https://files.facepunch.com/forum/upload/483/3139fe4b-2b96-43b9-886c-45342c7ea6fa/hash%23.PNG

https://files.facepunch.com/forum/upload/483/82c65f9a-5142-4ae1-9042-1dec9d9b3757/hash%23.PNG

https://files.facepunch.com/forum/upload/483/1eb168a6-78c6-49ea-a33d-3b341ce15df7/hash%23%20-%20Copy.PNG

I'm not familiar with Azure but surely it includes something to parse url paths into valid escaped urls?

[Scratch]

Azure docs state
Reserved URL characters must be properly escaped.

Because while testing,

https://files.facepunch.com/forum/upload/1755/7eccfef6-de5a-4c41-bec3-989feee0f620/image.png

First line is the line I sent to azure, the bottom is what I got sent back
instead of
abcdefghijklmnopqrstuvwxyz+ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+_%2B-.%2C!%40%24%25%5E%26()%3B'.png.png
Which is what it would be completely escaped (that plus s really weird though... should be %20 ???)

A hash though is very special.
If you read some of the code I made (or understood it) azure accepts a submitted hash for the request if you remove the part of the filename from where the hash is onwards, then using that as the filename before you sign it

it's really weird

[Scratch]

https://files.facepunch.com/forum/upload/1755/017ff260-7e52-418f-8459-2156b30adcc8/image.png

🤷‍♀️

[Plaster]

So its unfixable until Microsoft does something?
Unless the browser can rename it before uploading maybe

[Scratch]

Yup

[PacificV2]

You shouldn't use pound signs when uploading things to the internet, since the pound sign has a special meaning. As per what defines an URL, RFC 1738:
The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it

What file uploaders do is replace the pound sign by "%23" (aka escaping the URL), which facepunch did when uploading your stuff to S3 (not azure), your uploaded files are actually all here, we just have to escape the URL ourselves.
For some reason the frontend is trying to fetch the image by its original name pre-escape?? It's a frontend issue.