{"action":"created","issue":{"url":"https://api.github.com/repos/expressjs/multer/issues/133","labels_url":"https://api.github.com/repos/expressjs/multer/issues/133/labels{/name}","comments_url":"https://api.github.com/repos/expressjs/multer/issues/133/comments","events_url":"https://api.github.com/repos/expressjs/multer/issues/133/events","html_url":"https://github.com/expressjs/multer/issues/133","id":72872852,"number":133,"title":"Should req.files be an array?","user":{"login":"LinusU","id":189580,"avatar_url":"https://avatars.githubusercontent.com/u/189580?v=3","gravatar_id":"","url":"https://api.github.com/users/LinusU","html_url":"https://github.com/LinusU","followers_url":"https://api.github.com/users/LinusU/followers","following_url":"https://api.github.com/users/LinusU/following{/other_user}","gists_url":"https://api.github.com/users/LinusU/gists{/gist_id}","starred_url":"https://api.github.com/users/LinusU/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LinusU/subscriptions","organizations_url":"https://api.github.com/users/LinusU/orgs","repos_url":"https://api.github.com/users/LinusU/repos","events_url":"https://api.github.com/users/LinusU/events{/privacy}","received_events_url":"https://api.github.com/users/LinusU/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":27,"created_at":"2015-05-03T22:07:16Z","updated_at":"2015-06-16T14:53:05Z","closed_at":null,"body":"I'm really unsure of this myself, but I wanted to get the discussion started. Should `req.files` be an array?\r\n\r\nIt would certainly help #59 since there then would be only one array to check. I also think that the most common case is having one file upload which then would be really easy to find, `req.files[0]`.\r\n\r\nThe downside would be pages that has multiple files with different fieldnames, it would be a bit more complicated to find a specific file.\r\n\r\nTo mitigate that we could expose a `byFieldname(fieldname, multiple)` function. `fieldname` would obviously be the filename and `multiple` would be a boolean on wether to allow multiple files or not. It would default to `false`.\r\n\r\nIf `multiple` is `false` and there is more than one file uploaded to that fieldname, I think that it should throw an error.\r\n\r\nOn top of this we could also expose a `byMimetype(mimetype, multiple)` function. That could help with sites that allows uploading any files, and then want to treat music, pictures or movies differently.\r\n\r\nAlthough I feel that we are maybe providing a bit too much with the functions. If `req.files` is just a normal array, it's very easy to do this with both built in functions, and already popular libraries.\r\n\r\n*examples*\r\n\r\n```javascript\r\n// Find all the new photos that should be added to the album\r\nreq.files.filter(function (file) {\r\n  return (file.fieldname === 'photo')\r\n})\r\n```\r\n\r\n```javascript\r\n// Check if the user has uploaded a new profile picture\r\n_.find(req.files, function (file) {\r\n  return (file.fieldname === 'profile-picture')\r\n})\r\n```\r\n\r\n```javascript\r\n// Convert all audio files to ogg/vorbis\r\nreq.files.filter(function (file) {\r\n  return is.is(file.mimetype, ['audio/*'])\r\n})\r\n```"},"comment":{"url":"https://api.github.com/repos/expressjs/multer/issues/comments/112459911","html_url":"https://github.com/expressjs/multer/issues/133#issuecomment-112459911","issue_url":"https://api.github.com/repos/expressjs/multer/issues/133","id":112459911,"user":{"login":"LinusU","id":189580,"avatar_url":"https://avatars.githubusercontent.com/u/189580?v=3","gravatar_id":"","url":"https://api.github.com/users/LinusU","html_url":"https://github.com/LinusU","followers_url":"https://api.github.com/users/LinusU/followers","following_url":"https://api.github.com/users/LinusU/following{/other_user}","gists_url":"https://api.github.com/users/LinusU/gists{/gist_id}","starred_url":"https://api.github.com/users/LinusU/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LinusU/subscriptions","organizations_url":"https://api.github.com/users/LinusU/orgs","repos_url":"https://api.github.com/users/LinusU/repos","events_url":"https://api.github.com/users/LinusU/events{/privacy}","received_events_url":"https://api.github.com/users/LinusU/received_events","type":"User","site_admin":false},"created_at":"2015-06-16T14:53:04Z","updated_at":"2015-06-16T14:53:04Z","body":"@jpfluger Why I'm pushing for this is to push our users into securing up there apps. Most likely everyone needs to go thru and make some small tweaks for it to work with this new version. We have removed almost every option that was available before and replaced it with a much simpler api.\r\n\r\nSo since we will have breaking changes either way, I think it's a great opportunity to make sure that we are \"secure by default\". Not leaving our users vulnerable by just using the module with the default settings.\r\n\r\nThe reason why I don't want to have `allowedFields` optional is that I think that many users will miss it. People writing tutorials or people answering questions on StackOverflow will want to show code that works with as few lines as possible, and it's often implied that it might not have been reviewed from a security perspective.\r\n\r\nI think that there are two questions that we should try and answer.\r\n\r\n**1) Will the user be required to make changes when upgrading.**\r\n\r\nAs it is now this is a yes since the options object have changed very much. If we wan't backwards compatibility we have a bit more to go, but the point that I had when making this branch was to introduce breaking changes.\r\n\r\n**2) Do we want the library to be secured by default and let the user open up what functionality it need, or should the library be open by default and it's the users responsibility to tighten the security?**\r\n\r\nGiven that javascript is a very accessible programming language there will probably be many users of this library that are quite new to this. I think that we should take it upon ourselves to make multer as secure as possible out of the box.\r\n\r\nUsing the functions that I provide (and I'm open to any other suggestions) we will provide a solution *where it is as easy to be secure* as it is to allow all. I think that this is they key to helping everyone to achieve good usage.\r\n\r\nThe problem with optional security is that it's easy to forget or to think that \"we will fix that before we release\".\r\n\r\n"}}