+1. some kind of metadata is needed.
- James Snell
IBM Emerging Technologies
[EMAIL PROTECTED]
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
Jess Sightler <[EMAIL PROTECTED]>
01/30/2003 02:00 PM
Please respond to axis-dev
To
[EMAIL PROTECTED]
cc
bcc
Subject
Re: Axis attachment naming enhancement (code attached)
Perhaps the real solution is to make Axis store the filename somewhere
(perhaps in a file like Axis98765axis.properties)? I agree that letting
the client control the server filename is a security risks, but carrying
meta-data, such as whether or not the file is a .exe file) is useful.
On Thu, 2003-01-30 at 16:43, James M Snell wrote:
> I would think that allowing the client to control the naming of the
files
> saved on the server would constitute a security risk on the server. If
> the attachment contains a malicious executable, then Axis would be
> unwittingly allowing the code to be saved to the server in a form that
> would allow it to be easily executed (e.g. tempfilename.exe). While I
> recognize the benefits that something like this would allow, I do not
> believe that this is the right solution.
>
> - James Snell
> IBM Emerging Technologies
> [EMAIL PROTECTED]
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
>
>
> Jim Lerner <[EMAIL PROTECTED]>
> 01/30/2003 12:10 PM
> Please respond to axis-dev
>
>
> To
> [EMAIL PROTECTED]
> cc
>
> bcc
>
> Subject
> Axis attachment naming enhancement (code attached)
>
>
>
>
>
> I am submitting for your approval (and integration) changes to
> Axis-1_1beta that allows Axis to create unique names for file
> attachments that bear a passing resemblance to the original filename.
> This is critical for applications that use the filename [extension] for
> disambiguation, and also in the case of multiple attachments on a single
> message. It's my understanding that there are a number of Axis users
> out there who have suffered for lack of a solution to this problem.
>
> The premise is simple: add a MIME header to each attachment with the
> original filename. When the file is sent to Axis, Axis'
> ManagedMemoryDataSource will use this name to create a uniquely named
> temporary file (eg. Axis98765_myfile.xls) rather than the usual
> (Axis98765axis). Likewise, when Axis receives a file to be sent back to
> the caller, a MIME header on the attachment indicates the original name
> (Axis98765_myfile.xls). This is not quite optimal, but it is easy
> enough for the client to parse and use, given that the underscore is
> guaranteed to be the first one in the filename. Existing applications
> that don't set the MIME header will continue to see the previous file
> naming behavior.
>
> The changes that I've made (in the attached files) are as follows:
>
> org/apache/axis/transport/http/HTTPConstants:
> added HEADER_X_ORIGINAL_FILENAME for new MIME header
>
> org/apache/axis/attachments/AttachmentPart:
> setMimeHeader(DataSource's getName()) when creating an attachment part
> from a DataHandler and
> when setting a DataHandler for an existing AttachmentPart.
>
> org/apache/axis/attachments/MultiPartRelatedInputStream:
> inform ManagedMemoryDataSource of the X_ORIGINAL_FILENAME MIME heading.
>
> org/apache/axis/attachments/ManagedMemoryDataSource:
> added new constructor with extra parameter for original name (other
> constructors use this(..., null))
> added storage for the original filename
> use the original name when constructing the temporary file into which
> the in-memory file is flushed.
>
> Please let me know if you need any further clarification, any of this
> needs to be reworked, etc. I'm hoping that you'll find this to be
> useful, correct, and worth integrating into the CVS repository.
>
> - Jim
>
>
>
>
>
>
>
--
=======================================
Jess Sightler
Senior Developer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================
