Re: [Zope] Images and uploading
What might help in your case is the ExtFile/ExtImage product. It deposits binaries in a directory on the server but also creates Zope objects to access that file. It uses the Python Imaging Library for the handling of Images. I assume PIL does not use file endings but header info from the files to detect the filetype you probably still need to actually create the object to do some checking or subclass ExtImage in Python to provide some more error checking . Harald At 12:13 PM +0100 2/28/01, Paul Zwarts wrote:
So the question is, how do I get an attribute of an object while its still masquerading in the REQUEST as an upload instance....? Other reasons being is that on my old system, (its a link databse) hackers tried to upload .exe's thinking they could get a server-side trojan running, so I provide some kind of error checking....
Thanks Harald, I do indeed have ExtFile loaded on my system, and had ignored it for the sake of figuring out LocalFS. Will give it a look now, but will it really help? It sounds like the same conundrum except that when depositing a file somewhere, the meta data is in fact captured and stored, and can be requested after is deposit. But what I want is this operation to occur beforehand..... Which makes me ask, how do I access the physical path of an HTTPRequest.upload.instance so I can perform a string.search? Paz Harald Scheirich wrote:
What might help in your case is the ExtFile/ExtImage product.
It deposits binaries in a directory on the server but also creates Zope objects to access that file. It uses the Python Imaging Library for the handling of Images.
I assume PIL does not use file endings but header info from the files to detect the filetype you probably still need to actually create the object to do some checking or subclass ExtImage in Python to provide some more error checking .
Harald
At 12:13 PM +0100 2/28/01, Paul Zwarts wrote:
So the question is, how do I get an attribute of an object while its still masquerading in the REQUEST as an upload instance....? Other reasons being is that on my old system, (its a link databse) hackers tried to upload .exe's thinking they could get a server-side trojan running, so I provide some kind of error checking....
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
If you want the error checking to be done before the saving using ExtImage you probably would have to change extImage to do so and modify not to write anything that cannot be recognised as webviewable. Using LocalFS you could write an External python function To check the data that you get via PIL to assert that the data that has been sent actually is an image befor it is written making this up as i go along e.g. I dont know if something like this would work --------------------- # file is REQUEST['file'] where file is the # form name for the input element from PIL import Image def isImage(file) try: im = Image.fromstring(data) except: return false return true --------------------- I havent worked with LocalFS which i think HTTPRequest.upload.instance is from, is it ? Harald At 1:19 PM +0100 2/28/01, Paul Zwarts wrote:
Thanks Harald,
I do indeed have ExtFile loaded on my system, and had ignored it for the sake of figuring out LocalFS. Will give it a look now, but will it really help?
It sounds like the same conundrum except that when depositing a file somewhere, the meta data is in fact captured and stored, and can be requested after is deposit. But what I want is this operation to occur beforehand.....
Which makes me ask, how do I access the physical path of an HTTPRequest.upload.instance so I can perform a string.search?
Paz
Hi.... Just as FYI, since I was able to get A solution, but probably by far, not a very good one: <dtml-var "image.filename[_.string.index(image.filename,'.'):]"> Where image is the <input type="file" name="image"> of a form. I was able to query that content-type by <dtml-var "image.headers"> but could not further render the tuple to access anymore than image.filename which seems to be contained inside image.headers. Strange or stupidity on my part? Anyhow, the .string.index [start:end] worked quite well. Im a happy camper. Im glad I was able to crack it with LocalFS because it was enough of a pain in the butt to make me not want to jump into cold water with ExtFile.... But thanks very much for your help anyways, Harald. Paz Harald Scheirich wrote:
If you want the error checking to be done before the saving using ExtImage you probably would have to change extImage to do so and modify not to write anything that cannot be recognised as webviewable.
Using LocalFS you could write an External python function To check the data that you get via PIL to assert that the data that has been sent actually is an image befor it is written
making this up as i go along e.g.
I dont know if something like this would work --------------------- # file is REQUEST['file'] where file is the # form name for the input element
from PIL import Image
def isImage(file) try: im = Image.fromstring(data) except: return false return true ---------------------
I havent worked with LocalFS which i think HTTPRequest.upload.instance is from, is it ?
Harald
At 1:19 PM +0100 2/28/01, Paul Zwarts wrote:
Thanks Harald,
I do indeed have ExtFile loaded on my system, and had ignored it for the sake of figuring out LocalFS. Will give it a look now, but will it really help?
It sounds like the same conundrum except that when depositing a file somewhere, the meta data is in fact captured and stored, and can be requested after is deposit. But what I want is this operation to occur beforehand.....
Which makes me ask, how do I access the physical path of an HTTPRequest.upload.instance so I can perform a string.search?
Paz
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (2)
-
Harald Scheirich -
Paul Zwarts