Cannot programmatically download Attachment

I still have not been able to resolve this. Could someone perhaps guide me on how I could fix this? I am willing to try to write a patch or a custom module, but I'm not sure where to begin.

Is this happening on 6.2.x? 6.1.x is not supported.

It was on 6.1, but I'll update to 6.2 and re-test.

I have updated my environment to the following:
Drupal core 10.1.6
Webform 6.2.0

I have imported the attached webform and tested a submission. Submission works as expected. Attachment is generated as expected and can be accessed via the submission ui. However, it is not automatically downloaded as expected according to the config (see screenshot).

When you say “programmatically” is the custom program a key fixture in the bug reproduction, or is the bug about the inability to download the attachment by any means?

The "programatically" aspect of this ticket is key to me. :-) I have tried the following to access the attachment link from a custom Webform Handler:

$account = User::load(1);
$this->accountSwitcher->switchTo($account);

// Save and get the submission results.  This is all successful except when trying to download the attachment with:

file_put_contents($destination, file_get_contents($attachment_url));  // Works if Anonymous users have "Administer webforms" permission.  Doesn't work otherwise.

$this->httpClient->get($source, $this->configuration['guzzle_options']); // Denied access unless Anonymous users have "Administer webforms" permission.

curl url/to/attachment/path  // Administrator has access to download but the file is malformed (the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded).

$this->fileSystem->saveData($attachment_url, $destination, FileSystemInterface::EXISTS_REPLACE);  // Administrator has access to download but the file is malformed (the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded).

Actually I just tried curl again, and for some reason that worked this time. I don't know what's different.

In what context is that custom code executing? If it is on the Drupal site, it shouldn’t be necessary to make HTTP calls to obtain webform files.

I am writing a custom module with a custom Web Handler on a Drupal site.

Perhaps if we could “zoom out” and understand succinctly what your requirements are.

Thank-you for your patience. :-)

I want to programmatically download a Webform attachment without having to open up the permissions to access the Webform attachment to anonymous users.

Why do you need to download attachments when your code is, I think, running on the Drupal instance that has the attachments? You could directly access those files in that context. Where are you intending to download them from or to?

I am setting this to a support request until we understand this is a bug.

I have a client requirement to upload that attachment to their BOX client via an API.

When you load a submission object, you have access to its files, and I am saying this as someone who has written a relatively big Webform integration module that handles files. I don't see any way you would have to "download" the files to work on them in a submission handler. The files are already in Drupal's file system.

I hope this makes sense.

I can see that when I inspect the webform submission using Xdebug and by looking in Drupal's file system that what you say is true for any files uploaded to the webform by the submitter. However, fields of type attachment that generate a pdf of the submitted form (please see the example form and screenshot), are generated AFTER the form is submitted and does not seem to be available in the file system. I can only access them via the url generated by Webform after the file is generated.

I believe this might be related: https://www.drupal.org/project/webform/issues/3419954 💬 'Attachment URL' element with tokens gives 'Connection refused for URI' error Active

I can get to this to work using the access token from webform submission. This can be closed.

Automatically closed - issue fixed for 2 weeks with no activity.