Page MenuHomePhabricator

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

Assigned To
Authored By
Quiddity
Jun 16 2022, 7:45 PM
Referenced Files
Restricted File
Jul 22 2022, 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
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?:

→ Note that Phabricator/Phorge has an "Attach" feature on Files. It means that, if a private File is attached to a Task, the persons that can see the Task can also see the File. This is also easier and more secure to setup, than manually keeping in sync Files permissions with their related Tasks permissions.

→ In short, probably, Drag & Drop should attach as default.


Upstream Task in Phorge:

https://we.phorge.it/T15106

Related Objects

Event Timeline

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

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.

Hi, adding a related scenario where an image is defaulting to Private access is when it is Copy+Pasted into a comment on a Phab task. For example in T253706#8338190

Reedy mentioned this in Unknown Object (Task).Nov 9 2022, 8:18 PM

Thank you very much for the step-by-step fix up at https://www.mediawiki.org/wiki/Phabricator/Help#File_visibility with all the rationale behind the issue. That is great to have around and served me well.

thcipriani lowered the priority of this task from Medium to Low.May 24 2023, 4:54 PM

Part of this workflow still needs fixing, but this will happen post-phorge migration.

https://www.mediawiki.org/wiki/Phabricator/Help#File_visibility states:

Files uploaded while editing/creating/commenting on a task are private, and visible to no one except the file's uploader and the subscribers of the task that they are attached to.

I'm confused because I think files uploaded to a task are visible to anyone opening that task, not just "subscribers". I can definitely see images I attached to tasks even if I'm logged out from Phabricator. Unless the sentence refers to tasks with restricted visibility, but it should be noted.

@fnegri In the past I've seen cases where I could view the task without doing anything, but I had to subscribe to the task to view the attached files. That may have been a bug though (or just messed up policies on the specific task/file), it's not definitely not common and I can't even find an example now. I corrected that page.