-
-
Notifications
You must be signed in to change notification settings - Fork 237
Server crashes during image manipulation #550
Comments
Thank you, it helped me to solve my problem. |
I just ran into this same issue a week ago while testing. I think everyone using this library will have this issue if they bothered to test uploading bad files. Something should really be rolled into this package to handle this - that is if it were being maintained, as this is a huge bug. Basically the THANK YOU for this solution! It works good to catch a bad file and then clean things up in your Collections. My only issue is there still doesn't seem to be a way to throw an error back out to the client Same issue here with a different approach: #598 |
Just a heads up, I've been doing more testing and it looks like there's plenty of file types that will NOT cause List of Graphics Magick compatible file types: http://www.graphicsmagick.org/formats.html |
Update - There's a nice work-around here: |
Hey all, This could potentially be used by malicious users to DOS an application. I've accepted a PR to add an alert to |
@wursttheke Having this same issue but can't get the server to stop crashing. What do you mean by delete the temp file? I've cleared all tempstore collections in the db, butt still nothing |
I had the same problem with Windows 10, I switched to Ubuntu 16.04 operating system and works perfectly .. 07 Sep 2016 .. sorry my English .. |
If you define a
transformWrite
function as described in the docs with some image manipulation like this:When you now upload an erroneous image file, e.g. a simple text file with an image file extension like
mytext.png
it will result in a server crash, becausegm
can't identify it as an image:And somehow (I think because of the automatic retry feature) it will just keep crashing if the server restarts. You would have to delete the temp file to sort of 'fix' the situation.
My current (working) solution is to first do a
gm.identify
and then catch a possible error:Couple things to notice here.
Meteor.bindEnvironment
for the callback to work the meteor way.Perhaps there is a more elegant way to this, I'm not seeing.
People upload nasty things, so I think this is something that should be handled by the package in an elegant 'non crashing' way. Deleting the
fileObj
is certainly not what you want to do. Maybe anerror
field could be written to it to inform the user something went wrong.The text was updated successfully, but these errors were encountered: