Page MenuHomePhabricator

Uploaded files via the drag-and-drop are defaulting to private-access
Open, MediumPublicBUG REPORT

Assigned To
Authored By
Quiddity
Jun 16 2022, 7:45 PM
Referenced Files
Restricted File
Fri, Jul 22, 12:37 PM
Restricted File
Jun 28 2022, 6:00 PM
F35284644: image.png
Jun 28 2022, 5:35 PM
F35284642: 640px-Dinosaur_-_stegosaurus_(PSF).png
Jun 28 2022, 5:33 PM
F35284639: 640px-Dinosaur_(PSF).png
Jun 28 2022, 5:31 PM
F34663344: image.png
Jun 20 2022, 6:59 PM
File Not Attached
Restricted File
Jun 17 2022, 3:51 PM
F35247591: Screen Shot 2022-06-16 at 4.07.31 PM.png
Jun 16 2022, 8:08 PM
Tokens
"Love" token, awarded by Krinkle."Love" token, awarded by RHo."Burninate" token, awarded by Jdlrobson.

Description

List of steps to reproduce

  • If we drag and drop an image into Phabricator (Description or Comment or Phame post), it seems to be setting the default visibility to only the uploader. *E.g. https://phabricator.wikimedia.org/T310785#8008970 which just shows me {F35246875, size=full}
  • However if we use the "upload file" form, then things work as expected.

What happens?:

What should have happened instead?:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

It looks like there's a 3-step workflow for making attached images public (if we used drag-and-drop to upload). I will test it on these 3 files, but leave out the original in the Description.

2022-06-16_12-56.png (413×396 px, 25 KB)

2022-06-16_12-57_1.png (491×917 px, 65 KB)

2022-06-16_12-57.png (560×987 px, 64 KB)

I'll put some money on this upstream change having something to do with it, if only from the name of the file changed.... "webroot/rsrc/js/core/behavior-drag-and-drop-textarea.js"

However if we use the "upload file" form, then things work as expected.

for me this issue is also present when I use the "upload file" form. just added an image test to T306562 via the "upload file" form.

logged inlogged out
Screen Shot 2022-06-16 at 4.08.16 PM.png (761×1 px, 109 KB)
Screen Shot 2022-06-16 at 4.07.31 PM.png (991×1 px, 355 KB)

(note: the images in this comment were uploaded using the "upload file" form, then edited via the phabricator URL, e.g. https://phabricator.wikimedia.org/F35247591)

See:

I haven't really dug into this yet. To summarize my current understanding, I think it's mostly working as intended but is a fairly bad user experience and may have glitches. I also think some amount of further work is planned upstream, but I don't know how much we should rely on that.

I'll try to check those assumptions.

Also noting that "upstream" is a bit fuzzy here - this is a change coming from Phacility, but we should also probably talk about it with Phorge folks.

I don't think this is new behavior in that they have always defaulted to the uploader. It's just noticeable now because files don't get attached automatically. They should get automatically attached when you drag-and-drop, but this isn't working due to T310850.

Note this also applies to copy and paste, which is the workflow I use the most often for partial screenshots. Hopefully any fix will apply to both use cases, but just a note that to test that as well.

I think it's mostly working as intended but is a fairly bad user experience and may have glitches.

This seems like a particularly bad user experience -- I'm not sure I've ever used the upload form, I mostly copy-paste screenshots in, with occasional drag-drop.

It does sound like Phabricator is supposed to already be coping with this, from the upstream ticket:

However, Phabricator can determine that an attachment is expected and safe in some common cases, like dragging a file into a comment area: when you do this, Phabricator will automatically generate an appropriate "attach file" action as part of the comment.

So maybe the current bad behavior is a temporary glitch and can be quickly fixed? But of course...

These behaviors may improve in a future release of Phabricator, but see also the "no longer actively maintained" banner and don't hold your breath.

{F35249270}

D1203: Support automatic file attachment in most upload workflows adds support for all upload workflows, so you can use the edit form upload dialog, copy-paste, or drag-and-drop. Resolving T310850 alone will fix attachment workflows for copy-paste and drag-and-drop though.

Isn't it funny that this thread contains images I can't see? Namely https://phabricator.wikimedia.org/F35249270: "Access Denied: Restricted File. You do not have permission to view this object. Users with the Can View capability: @DLynch".

My team is currently running into this with every screenshot we try to attach to a ticket. The experience is rather painful, and I find it very unclear how to resolve from it. For example, I found these red "File Not Attached" warnings in the sidebar on the right. I can click it and confirm the two popups that show up, and the red warning disappears. Still when I look at the file individually it still says I'm the only one who can view it. What's going on?

TL;DR: Can we please make files public by default, as it was before?

@thiemowmde This will be resolved once our Phabricator deployment is fixed, see T310850. As I understand, it has a build process you have to execute before deploying, and was executed wrong or something. Phabricator's actual code handles this correctly, when it's deployed correctly.

Isn't it funny that this thread contains images I can't see? Namely https://phabricator.wikimedia.org/F35249270: "Access Denied: Restricted File. You do not have permission to view this object. Users with the Can View capability: @DLynch".

I thought that was the joke :)

My team is currently running into this with every screenshot we try to attach to a ticket. The experience is rather painful, and I find it very unclear how to resolve from it. For example, I found these red "File Not Attached" warnings in the sidebar on the right. I can click it and confirm the two popups that show up, and the red warning disappears.

Clicking through those popups from the sidebar is indeed the way to resolve the problem.

Still when I look at the file individually it still says I'm the only one who can view it. What's going on?

TL;DR: Can we please make files public by default, as it was before?

This has always been the case. If you upload the file through the form at https://phabricator.wikimedia.org/file/upload/, it will be public; if you upload it while commenting on a task etc., it will be only visible to you, but it will also be visible to all subscribers of tasks etc. that it is attached to – just the internal method of attaching it has been changed. Here's an example file I uploaded last year which behaves in the same way: F34663344

Just echoing the concerns above: this is causing a lot of confusion in my team's workflow. In particular, we're getting inactionable bug reports because of restricted images, and the workflow for fixing it appears challenging.

+1 it would be super appreciated if this can be resolved soon. It is causing more work and lost time for design team folks who tend to upload a fair amount of images on tasks. Besides the added steps needed right now, the fact that a person uploading or copy+pasting can see the image makes it easy to forget to even take those extra steps to change view permissions/attach the file.

brennen triaged this task as High priority.Jun 22 2022, 7:02 PM

I am aware of the severity of the issue. We have a fix; I will get it deployed as soon as I can manage.

Thanks, @brennen ! I know you folks have a lot going on and really appreciate your attention on this. :)

RHo awarded a token.

Is this actually resolved? I saw it still occurring in a comment left yesterday (which has been manually fixed since -- the first two images were unattached, though).

Another public domain dinosaur test:

640px-Dinosaur_(PSF).png (361×640 px, 96 KB)

A public domain dinosaur test for the upload button:

640px-Dinosaur_-_stegosaurus_(PSF).png (415×640 px, 73 KB)

A public domain dinosaur test for the copy-and-paste action:

image.png (385×640 px, 143 KB)

brennen added a subscriber: EAkinloose.

All I can say definitively at the moment is that this seems to automatically attach files for me when uploaded via the three paths I know about. I can easily imagine that I'm missing something; I'll poke at my dev install and see if I can figure out anywhere this doesn't happen.

@EAkinloose, did you happen to notice anything unusual while uploading the screenshots in https://phabricator.wikimedia.org/T310197#8031652 ?

I imagine it could happen if you copy-paste (or drag-and-drop) the files on one task, then cut-and-paste the {F....} markup into another task.

Here's an example, let's see: {F35284673}

And indeed. I don't think it's possible to make this work automatically with Phab's new model for attachments, though? We might want to just document how to fix it when it happens.

I imagine it could happen if you copy-paste (or drag-and-drop) the files on one task, then cut-and-paste the {F....} markup into another task.

Hmm, yeah, that seems like a plausible mechanism. I'll leave this open in case anyone has run into anything else.

And indeed. I don't think it's possible to make this work automatically with Phab's new model for attachments, though? We might want to just document how to fix it when it happens.

Yeah, I can add something to https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments

Thanks, @matmarex . If I'm understanding correctly, restoring the original functionality is not possible due to Phab's new model for attachments. If that's the case, while documenting how-to is important, I think it's more important for the Phab UI to give instructions. The issue I'm hearing from folks is not that they don't know how to fix the issue, but that they forget (or, in the case of bug reporters, don't realize), because it's not intuitive.

Anyone know the process for getting a UI element added? For example, a message that pops up whenever a file is uploaded/pasted/dragged-and-dropped that says "take X steps to achieve visibility."

The original functionality has been mostly restored now, as long as you don't do something craaaaazy like copy-pasting plain text markup to another task. If you just upload files on a task, they should be visible with no further steps needed. (On the other hand, I've seen two people run into this problem this week already.)

I added more details in https://www.mediawiki.org/wiki/Phabricator/Help#File_visibility and I'd be fine with just giving people this link when their files are not visible to me.

Ah, OK, great, thanks for the clarification. I'll keep an eye out.

copy-pasting plain text markup to another task

Do you mean like pasting the bracket number for an image? e.g.

{F35284673}

Yes (although I should have said "cut and pasting", because this only occurs if you remove it from the task where you originally uploaded the file, which prevents it from being attached there).

brennen lowered the priority of this task from High to Medium.Jul 5 2022, 1:06 PM

@matmarex thanks for the documentation changes. I can probably investigate some further UI tweaks, but I'll avoid making any promises about timing.

T312864 features a variant of this still happening. Jon added the second image in the description via editing the description after the task was created (but still via drag-and-drop upload), and this presumably bypassed the automatic permission setting.

Jon added the second image in the description via editing the description after the task was created (but still via drag-and-drop upload), and this presumably bypassed the automatic permission setting.

Thanks for the heads up. That does sound plausible; I'll investigate.

This also happens when editing comments.

Edit: Here's a pasted image: {F35330159}

Granted, my understanding is that "automatically enabling access to files that're in edited-content" is the exact security loophole that this annoyance was introduced to avert... but it seems like there should be some way to have phabricator notice-and-allow fresh uploads in that situation while still ignoring the hypothetical malicious contents.