If that’s the case, do you think a sanitize method is more appropriate for this situation? Perhaps one that could live inside an interceptor and possibly even be overridden by those who think they know what they’re doing? This way you wouldn’t have to reject the upload which in my opinion is not a preferred user experience.
> On Feb 12, 2025, at 12:56 PM, Brian Andle <brianandle...@gmail.com> wrote: > > Unless I'm mistaken this is to prevent issues when a developer 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 <burtonrho...@gmail.com> wrote: >> >> I agree with 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 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 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" <gregh3...@gmail.com> >> To dev@struts.apache.org >> 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 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! >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >>
