Running fetch manually works.
Running cron while logged in through status report works.

Visiting http://example.com/cron.php while not logged in causes mail to be retrieved, tickets and users to be created, attachments saved to /files, but the attachment is not attaching to the ticket.

CommentFileSizeAuthor
#4 support_attachments.patch1.23 KBjeremy
#2 support_attachments.patch1000 bytesjeremy

Comments

last call media’s picture

last call media commented

Setting the permission for anonymous to upload files makes this work. So maybe this is really a feature request to allow the files to attach without having to set this global permission to anonymous.

jeremy’s picture

jeremy commented
Status: Active » Needs review
StatusFileSize
new support_attachments.patch1000 bytes

I can confirm the bug. However offhand I don't have a good solution. The attached would probably work, but it's a bit of a kludge and a security risk. I'm open to ideas for a better solution.

slip’s picture

slip commented
Status: Needs review » Needs work

hmmm, this is an interesting issue. I'm also not seeing a clean solution at first glance.

In terms of security of the first patch, this is the first thing that needs to be taken care of: http://drupal.org/node/218104

Second, you can always run cron as an authenticated user: http://drupal.org/cron ... that should solve the problem, so I'm not positive anything needs to be done.

I see three options at the moment:
1) A patch similar to #2 after some security improvements. Seems like it should get the job done pretty well...
2) The only thing it looks like the lack of the permission is preventing is a call to upload_save($node); so I suppose it would be possible to call that function yourself without switching users and get the same effect.
3) tell users that if they want to use cron this way they'll have to run cron as a user with proper permissions. I'm leaning towards this at the moment. It seems like if your module is going to rely on a the upload module, you should respect its permissions settings.

Also, it seems like people could use the upload_perm_per_type module to make this setting less global.

Any others ideas? What do you guys think?

jeremy’s picture

jeremy commented
Status: Needs work » Closed (works as designed)
StatusFileSize
new support_attachments.patch1.23 KB

Thanks for your timely feedback, slip. I'm attaching an updated patch to address the security issues which people can feel free to apply.

However, I also agree that we really should be respecting the upload module's permissions, so this patch will not get merged. Instead I have updated the INSTALL file to document this permission issue, including a link to the Upload Permissions Per Content Type module:
http://drupal.org/cvs?commit=294158

Marking as by design.

last call media’s picture

last call media commented

after thinking about it and chatting about it with slip, "by design" seems right since you are after all allowing uploads by anonymous if you want any one to be able to email attachments to your drupal site...

attachments saved to a private dir would be great.