> >> uses the
> > > > > > >> file name, unsanitized, and potentially other malicious type
> > > > > > >> injection via
> > > > > > >> specially crafted file names.
> > > > > > >>
> > > > > >>> On Wed, Feb 12, 2025, 10:05 AM Burton
> > > > > >>> Rhodes wrote:
> > > > > >>>
> > > > > >>> I agree with Greg.
> > > > > >>>
> > > > > >>> IMHO, characte
th Greg.
> > > > >>>
> > > > >>> IMHO, character validation should be left to the developer which
> > > > >>> depends
> > > > >>> on their OS and file names supported therein. But if there needs to
> > > > &g
n their OS and file names supported therein. But if there needs to be
> > > >>> protection against a buffer overflow attack (I assume that is the
> > > >>> problem you are trying to solve?), then the length restriction should
> > > >>> suffice. Or is there
a buffer overflow attack (I assume that is the
> > >>> problem you are trying to solve?), then the length restriction should
> > >>> suffice. Or is there another risk I'm not aware of that could threaten
> > >>> a system by just having a few malicio
> >>> a system by just having a few malicious characters in a file name?
> >>>
> >>>
> >>> Thanks,
> >>> Burton
> >>>
> >>>
> >>> -- Original Message --
> >>> From "Greg Huber&q
ving a few malicious characters in a file name?
Thanks,
Burton
-- Original Message --
From "Greg Huber"
[email protected]
Date 2/11/2025 2:51:36 AM
Subject Re: file upload name filtering
Filename length is a possible good way to go, with an override of the
length and th
>>
>> Thanks,
>> Burton
>>
>>
>> -- Original Message --
>> From "Greg Huber"
>> To [email protected]
>> Date 2/11/2025 2:51:36 AM
>> Subject Re: file upload name filtering
>>
>>> Filename length is
ther risk I'm not aware of that could threaten
> a system by just having a few malicious characters in a file name?
>
>
> Thanks,
> Burton
>
>
> -- Original Message --
> From "Greg Huber"
> To [email protected]
> Date 2/11/2025 2:51:36 AM
&
should
suffice. Or is there another risk I'm not aware of that could threaten
a system by just having a few malicious characters in a file name?
Thanks,
Burton
-- Original Message --
From "Greg Huber"
To [email protected]
Date 2/11/2025 2:51:36 AM
Subject Re: f
Filename length is a possible good way to go, with an override of the
length and then truncate or block option.
On 11/02/2025 06:21, Lukasz Lenart wrote:
Hm... looks like I must re-think this approach, thanks all for
reporting this issue!
; -- Original Message --
> From "Lukasz Lenart"
> To "Struts Developers List"
> Date 2/9/2025 11:50:30 AM
> Subject Re: file upload name filtering
>
> >Could you create a JIRA ticket to address this?
> >
> >niedz., 9 lut 2025 o 10:51
ng EXCLUDED_FILE_PATTERN =
"^(.*[<>&\"'|;/?*:]+.*|.*\\.\\..*)$";
Thanks,
Burton
-- Original Message --
From "Lukasz Lenart"
To "Struts Developers List"
Date 2/9/2025 11:50:30 AM
Subject Re: file upload name filtering
Could you create a JIRA
Could you create a JIRA ticket to address this?
niedz., 9 lut 2025 o 10:51 Greg Huber napisał(a):
>
> ..v6 to escape and warn would be good, and should reduce downstream
> complaints as they might not notice it😉.
>
> arthu€r.jpg
>
> long filenames to try and find the offending char
>
> af517d82-8
..v6 to escape and warn would be good, and should reduce downstream
complaints as they might not notice it😉.
arthu€r.jpg
long filenames to try and find the offending char
af517d82-8583-11eb-a3d0-06b4694bee2a_2Fmedia-manager_2F1738545771934-House_20&_20Home_20-_20HI-RES.png
On 09/02/2025 09:27
niedz., 9 lut 2025 o 10:20 Greg Huber napisał(a):
>
> Still using v6 at the moment, but I think v7 (dev box) is the same?
The same in functionality, but harder to refactor some things. I made
a few changes in the logic used in v7 and it's hard to port them back
into v6.
Anyway, I will take a look
Still using v6 at the moment, but I think v7 (dev box) is the same?
On 09/02/2025 09:14, Lukasz Lenart wrote:
niedz., 9 lut 2025 o 10:10 Greg Huber napisał(a):
I have now had a few uploads blocked mainly due to sentence punctuation
in the image name ie apostrophe and ampersand symbols.
It woul
niedz., 9 lut 2025 o 10:10 Greg Huber napisał(a):
>
> I have now had a few uploads blocked mainly due to sentence punctuation
> in the image name ie apostrophe and ampersand symbols.
>
> It would be better here to just escape the string and warn rather than
> just block it, requiring the user to r
I have now had a few uploads blocked mainly due to sentence punctuation
in the image name ie apostrophe and ampersand symbols.
It would be better here to just escape the string and warn rather than
just block it, requiring the user to remove the characters is a waste of
time as this can easily
This is rather a hardening to avoid potential feature security
vulnerabilities. In ParametersInterceptor we do not allow some certain
names of the parameters and the same should be used for uploading and
any other "user input".
Maybe it would be good to create one the same mechanism which can be
s
pon., 27 lip 2020 o 13:03 beppe coniglio napisał(a):
>
> Hi,
> I create a new Project following guide lines in
> https://cwiki.apache.org/confluence/display/WW/File+Upload but when I try to
> upload csv file I obtain "Content-Type not allowed:
> application/vnd.ms-excel"
> I download also a
Woohoo, I get it now... I saw the PrepareOperations before but digging w/o
an IDE is a pain.
Sweet--thanks again.
Dave
On Thu, Jun 21, 2012 at 4:11 PM, Łukasz Lenart wrote:
> 2012/6/21 Dave Newton :
> > Ah, okay--cool :) I don't see it in the ng filter dispatcher, but I'll
> track
> > it down
2012/6/21 Dave Newton :
> Ah, okay--cool :) I don't see it in the ng filter dispatcher, but I'll track
> it down later when I have a chance. Is there an elevator pitch for how the
> ng filter ends up calling it?
Take a look on the finally section of doFilter(), there is a call to
Prepare.cleanupRe
On Thu, Jun 21, 2012 at 3:51 PM, Łukasz Lenart wrote:
> I've changed a bit the whole cleanup idea, right now it's delegated to
> given implementation of MultiPartRequest, to the method cleanUp().
> So a filter calls Dispatcher.cleanUpRequest(request) which delegate to
> MultiPartRequest.cleanUp()
Hi Dave,
I've changed a bit the whole cleanup idea, right now it's delegated to
given implementation of MultiPartRequest, to the method cleanUp().
So a filter calls Dispatcher.cleanUpRequest(request) which delegate to
MultiPartRequest.cleanUp()
It works with old and with the new filters.
Regard
On Thu, Jun 21, 2012 at 12:05 PM, Dave Newton wrote:
> Anyone?
I am just guessing, but perhaps this?
http://y.ahoo.it/Qzl2h
--
Martin Cooper
> So far it appears as though the patch only fixed the old filter and not
> those of the ng variety?
>
> Also, I'm wondering if we'd like to un-"ng" thi
Anyone?
So far it appears as though the patch only fixed the old filter and not
those of the ng variety?
Also, I'm wondering if we'd like to un-"ng" this, or barring that, at least
re-package to something named better and put a subclass in ng and deprecate.
Dave
On Thu, Jun 21, 2012 at 6:14 AM
I ran into the same problem with inconsistent behavior when uploading
files. Sometimes i get a RequestFacade, and sometimes I get the right
MultiPartRequestWrapper.
I dug into the struts source code a little and I think I found the
culprit.
in org.apache.struts2.dispatcher.FilterDispatche
encounter this issue either.
liukaipeng
2007-01-06
发件人： cujsh
发送时间： 2007-01-05 02:53:07
收件人： [email protected]
抄送：
主题： file upload issue
All multipart request parameters coming back null on file upload
inconsistantly. Using struts2.0.1, tiles plugin 2.01. No exceptions thrown. One
fi
Susan Bradeen wrote:
Sorry for the traffic, however, Michael, you are taking some liberties
with James' name, aren't you?
No. I would rather discuss Struts.
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
On Tue, 05 Oct 2004 19:12:55 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
> James Mitchell wrote:
>
> >>Since you have not responded, Martin, I will assume for the moment that
> >>you agree with the foregoing.
> >>
> >>
> >
> >Michael, now why would you think that Michael? Is this your polic
James Mitchell wrote:
Since you have not responded, Martin, I will assume for the moment that
you agree with the foregoing.
Michael, now why would you think that Michael? Is this your policy when
participating in a public forum Michael? Did it ever occur to you that some
people, Michael, are
James Mitchell wrote:
Since you have not responded, Martin, I will assume for the moment that
you agree with the foregoing.
Michael, now why would you think that Michael? Is this your policy when
participating in a public forum Michael? Did it ever occur to you that some
people, Michael, are
ent: Tuesday, October 05, 2004 5:19 PM
Subject: Re: File Upload
> Michael McGrady wrote:
>
> > Martin Cooper wrote:
> >
> >> On Tue, 05 Oct 2004 00:01:14 -0700, Michael McGrady
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>&
Michael McGrady wrote:
Martin Cooper wrote:
On Tue, 05 Oct 2004 00:01:14 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
Hello, Martin,
What I am saying is very simple, and I am not sure what is the
difficulty.
As I've said, you are absolutely free to handle file uploads
however you wan
Martin Cooper wrote:
On Tue, 05 Oct 2004 00:01:14 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
Hello, Martin,
What I am saying is very simple, and I am not sure what is the difficulty.
As I've said, you are absolutely free to handle file uploads however you want.
The whole point
Martin Cooper wrote:
On Tue, 05 Oct 2004 00:01:14 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
Hello, Martin,
What I am saying is very simple, and I am not sure what is the difficulty.
As I've said, you are absolutely free to handle file uploads however you want.
The whole point
ße 11
80867 München
Phone +49-89-54 74 21 34
Fax +49-89-54 74 21 99
> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 5. Oktober 2004 17:05
> To: Struts Developers List
> Subject: Re: File Upload DEPRECATED?
>
> The package is
Michael McGrady <[EMAIL PROTECTED]> wrote:
> Is there a way that it would make sense in the future to allow
> developers using Struts to specify their own interface for multipart
> request handlers? This is probably a stupid suggestion but couldn't
> Struts leave the interface at something like
The package is *not* deprecated. What is deprecated is the old, buggy
implementation. The replacement is not Commons FileUpload, but is a
Struts wrapper around Commons FileUpload. See
CommonsMultipartRequestHandler. That implementation has been the
default implementation in Struts for quite some ti
On Tue, 05 Oct 2004 00:01:14 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
> Hello, Martin,
>
> What I am saying is very simple, and I am not sure what is the difficulty.
>
> >As I've said, you are absolutely free to handle file uploads however you want.
> >
> >
> The whole point is that this
I was on the commons users list, Vic, and Martin Cooper suggested
strongly that I move to the struts lists. Isn't this essentially a
developer's issue? Thanks. Michael McGrady
Vic Cekvenich wrote:
I think this should be on the users list. Commons-users list.
There are other file upload jars,
I think this should be on the users list. Commons-users list.
There are other file upload jars, such as Jason Hunter if this one does
not fit.
.V
(and... I do not see how file upload is a core competency of Struts,
it's similar to Tiles)
Michael McGrady wrote:
Hi, Mike,
I respond to your though
Hi, Mike,
I respond to your thoughts within. I am not creating a proposal,
perhaps I should say. I am just trying to find a clean way to implement
a file upload application.
Mike Stanley wrote:
Hi Michael,
I don't understand you're proposal. FileItem (from commons upload) is
an interface with
Hi Michael,
I don't understand you're proposal. FileItem (from commons upload) is
an interface with a factory. FileUploadBase (the parser) is abstract
with different implementations. Why would you wrap the interface
instead of simply creating a new concrete implementation of the above
mentioned
Niall Pemberton wrote:
Michael,
I'd rather you didn't tell other people what my views are (as you seem to
get it wrong most of the time). Although I wrote most of the wiki page your
refer to, Martin Cooper added the warning.
Niall
Thank you for that clarification, Niall. Martin, then, is the one t
PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 8:01 AM
Subject: Re: File Upload
> Hello, Martin,
>
> What I am saying is very simple, and I am not sure what is the difficulty.
>
> >As I've said, you are absol
For anyone interested in an option, what I would like to do is given
below. Anyone have any suggestions on the best way to do this and still
use ActionForm, short of rewriting ActionForm? Thanks for any
assistance. (The UploadFileItem is just a simple Serialized wrapper of
commons' FileItem.
Hello, Martin,
What I am saying is very simple, and I am not sure what is the difficulty.
As I've said, you are absolutely free to handle file uploads however you want.
The whole point is that this is not the case. The whole point is that
the present arrangement ties people to a specific way o
On Mon, 04 Oct 2004 22:04:23 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
> Martin Cooper wrote:
>
> >You already have two options - use what Struts provides, or disable
> >that and provide your own. Why would you want to bloat Struts with yet
> >another option?
> >
> >--
> >Martin Cooper
> >
Martin Cooper wrote:
You already have two options - use what Struts provides, or disable
that and provide your own. Why would you want to bloat Struts with yet
another option?
--
Martin Cooper
I will assume, and rightly so, that this is a serious statement.
There are two parts to an answer:
Pa
You already have two options - use what Struts provides, or disable
that and provide your own. Why would you want to bloat Struts with yet
another option?
--
Martin Cooper
On Mon, 04 Oct 2004 21:49:35 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
> Is there a way that it would make sense in
52 matches
Mail list logo
