search

microdotblog / issues

42 stars 0 forks source link

iOS app uses the name "image.jpg" for all image uploads to external blog #194

Open lildude opened 4 years ago

lildude commented 4 years ago

As with Sunlit (reported at https://github.com/microdotblog/sunlit/issues/131), the micro.blog iOS app is using the same hardcoded file name for all image uploads to external micropub blog - image.jpg - rather an a unique filename. I've not tested movies, but I suspect it is using the hardcoded movie.mov for movies.

This will result in images (and movies) being overwritten where updates are allowed on the destination endpoint, or a failure if updates are not allowed even when the images are different.

The filename should be a unique filename, possibly based on a UUID as the Sunlit XMLRPC upload does:

https://github.com/microdotblog/sunlit/blob/65567259f39b4739e1e80e40b3195aeaf426f9a4/Libraries/Snippets/Snippets%2BXMLRPC.swift#L158

manton commented 4 years ago

I think we can make the behavior match Sunlit. However, what you said about it overwriting existing files stands out to me as a server implementation detail and maybe a misinterpretation of the Micropub spec. I don't think there is anything in Micropub about updating existing files. It only says this:

The Media Endpoint MAY ignore the suggested filename that the client sends.

To update an existing file, it would be better to delete the file and then upload a new one. I think the Micropub spec assumes you are always creating new files with each upload.

I'm curious what your server is using? Micro.blog has been sending "image.jpg" for probably 3 years and it has never been a problem before with other servers that I'm aware of.

lildude commented 4 years ago

I'm slowly rolling my own server and it's been quite some time since I last read the spec closely so this is likely to be down to my interpretation of the spec... in this case: "MAY" == "mine won't" 😁.

Up until recently, I had been testing using web-based clients like Quill and they all used the original filename so I have been working on the basis a unique filename will always be sent by the client and that if the same file was sent as part of an update, it was a deliberate desire to replace the file, but I can see how this could be unintended.

manton commented 4 years ago

I think you should consider changing this "replace" behavior, since it's not documented in Micropub to work that way. As another example, let's say I'm an artist and I make a drawing in Photoshop and save it as "drawing.png". Then 2 months later I make another drawing and call it the same thing and upload it. I would be really surprise if that replaces the old file.

If you're not sure, you can check in the IndieWeb IRC/Slack to see if anyone else has run into something like this. My reading of the spec is that it implies you are always creating a new file. The spec says the server will generate a URL, return a "created" success message, etc.

The Media Endpoint processes the file upload, storing it in whatever backend it wishes, and generates a URL to the file. The URL SHOULD be unguessable, such as using a UUID in the path. If the request is successful, the endpoint MUST return the URL to the file that was created in the HTTP Location header, and respond with HTTP 201 Created.

lildude commented 4 years ago

Yeah, you make a good point there. I'll def change things up and will def head over to the IndieWeb IRC/Slack. Thanks for your time and feel free to close this when you're ready to.