New: Attachments!

(Régis Hanol) #1

Alongside its awesome image handling, Discourse now supports attachments.

You can already try it out on try where you can upload .txt, .csv and .log files.

If you want to enable attachments on your instance, you have to update the “authorized_extensions” setting. It’s pipe-separated list of all the extensions you want to allow.

For example, here’s the setting used on try: .jpg|.jpeg|.png|.gif|.txt|.csv|.log.

Sidenote: the check is only done on the extension of the file. Checking the actual content/encoding/mime-type of the uploaded file will be added later.

There’s 2 other settings you can customize:

  • max_attachment_size_kb: the maximum allowed size for attachments, independently of images (defaults to 1024 kB)
  • newuser_max_attachments: how many attachments a new user can add to a post (defaults to 0)

WARNING: if you change the max_attachment_size_kb, make sure you also update your web server’s request limit.

On the client-side, attachments work pretty much the same as images. You can use the upload button in the composer toolbar or drag & drop multiples files in the composer to attach them to your post.

The result will be inlined in your post like so: discourse.txt (18 Bytes)

Discourse will automatically add the size of the attachment and track all the clicks.


:file_folder: Attachment icon for topics with attachments?
Attachment filename not set on download
(Simon) #2

Great new feature!

However, there are several things I noticed:

  • The original file name is shown as the link text, but the downloaded file uses a “random” hex-string. I think this is very confusing. The file should have the same name as displayed.
  • The example log and csv files are sent as application/octet-stream, it would be better if it was using the correct MIME type.
  • The upload dialog does not tell me which kind of files/images are allowed. While this might be ok for image uploads, it should include a list of file types/extensions for other uploads.

Counter for attachments?
(Stephan) #3

Nice feature! Does this also work for files attached to an incoming mail?

(Régis Hanol) #4

That’s on my list. But it’s actually hard to do without complicating NGINX’s configuration.

@supermathie can you have a look at it? Seems to be missing from NGINX’s list of mime types.

You’re right. I’ll add that.

I actually didn’t test. But I’m pretty sure it does not. @eviltrout has been working on the mail integration. So he might dis/confirm this.

(Robin Ward) #5

It definitely doesn’t work via mail yet, but it’s something we can consider

(Anton Batenev) #6

What about antivirus hook when file is uploaded? For example, custom site setting to executable which accepts filename as parameter and return errno (ok | in progress, mark as unverified | failed).

(Jeff Atwood) #7

It will suffice for now to use hex plus actual filename.

(Jeff Atwood) #8

Unfortunately, very difficult to change… @zogstrip looked at this, and even as “concatenation of hex + filename” it is too difficult versus the improvement value.

Still looking into that with @supermathie but does this imply we need to change nginx settings every time that /admin setting of allowed filetypes is modified? Not sure.

This is definitively fixed. Test it on and see…

Perhaps at some later date, this does not feel like an urgently necessary feature to me, it would be complex and potentially even cause virus-spam-type issues. Do not want!

Will be blogging attachment support as a new Discourse feature soon, so any problems or issues or suggestions with attachments, please post them here now!

(Simon) #9

Hm, I really think just using the hex identifier makes attachments much more difficult to use and even useless for most non-technical people. Clicking on a download link named discourse.txt should result in a file with exactly that name in my download folder.

What exactly makes it so difficult to store the original filename? Maybe it would be easier to store the file using the original filename in a directory which is named after the hex identifier, for example:


(Adam Baxter) #10

In addition, you could send a Content-Disposition: attachment; filename=discourse.txt or Content-Disposition: inline; filename=discourse.txt header which would solve some of the problems (test with wget --trust-server-names to see the difference)

(Robert Lee) #11

Just dropping in to provide some feedback.

So far attachments have worked great, due to the nature of things over on the [url] Stonehearth Discourse [/url] these files have primarily been Qubicle Constructor files, but that doesn’t mean it’s not a useful feature.

I’m not entirely sure if the ‘click’ counter is working completely correctly? For example you can see it is counting in [url] this post [/url], however there is not one for [url] this [/url] . We are a version behind, so I’m not sure if that is part of the problem.

As for a future feature suggestions, a searchable file repository would be pretty handy, somewhere to simply just search through all the files uploaded to the forum - the current search function locates the filenames and takes you to the respective post, so perhaps something to indicate there is an uploaded file within that post?

(Jeff Atwood) #12

I moved 5 posts to a new topic: Sorry, file you are uploading is too big – but it isn’t

(Michael Brown) #13

nginx comes with a whole bunch of MIME types already defined, but types for .log and .csv files aren’t among them.

I wouldn’t recommend adding text/plain for .log files as they could be binary logs. But we can certainly add text/csv for .csv files.

Just add:

types {
    text/csv                    csv;

to a new file in /etc/nginx/conf.d or to your discourse.conf.

This is the Correct thing to do - we SHOULD be doing this.

We should probably send Content-Disposition: inline to hint to the browser that it can try and display the file in the browser (i.e. give the user the option of viewing it in the browser, think of a PDF) but give them a good filename if they choose to save.

(Michael Brown) #14

$ lynx -dump -head
HTTP/1.1 200 OK
Server: nginx/1.2.7
Date: Tue, 13 Aug 2013 16:23:57 GMT
Content-Type: text/csv

(Jeff Atwood) #15

I agree we should be setting the content disposition @zogstrip.

(Mario Colombo) #16

I just discovered another issue. If the post is advertised by e-mail, in the e-mail, the download link is relative, not absolute.

Example of file download link in e-mail:
flexReports_Dare_to_Ask.pdf(1.3 MB)

Link: http://uploads/default/27/57ecf8090f59456e.pdf instead of //

This results in e-mail users getting a 404 while in discourse, the link works just fine.

(Michael Brown) #17

To accomplish this, we’ll need to have the app handle the download.

One might hope that returning something such as:

HTTP/1.0 301 Over there, yo
Server: gunicorn/17.5
Date: Sun, 18 Aug 2013 02:54:57 GMT
Connection: close
Content-Type: text/plain
Content-Disposition: attachment; filename="adamcon 7 speech.txt"

would magically work, but it doesn’t. it’s treated as a standard redirect.

So perhaps we need something like:


(Sam Saffron) #18

The way you would take app control is by using XSendfile, it does complicate the nginx install a touch but gives you a bunch of other very cool features. For example: you could have a download location that requires a user be a logged on admin to download.

(Michael Brown) #19

Oohhhhhhh that is nice. OK yeah, I’m out of the web development loop. Does it show? :smile:

(Robin Ward) #20

I believe this was fixed in a recent avatar upgrade. Let me know if you see it again please!