Re: UploadedFilesAware SecurityMemberAccess:isAccessible message

I have my own stack, so I don't extend struts-default.

If <interceptor-ref name="fileUpload" /> is removed in 6.7 then there is 
no more maintenance overhead.😉

On 11/11/2024 13:04, Kusal Kithul-Godage wrote:
> Are you extending the 'struts-default' package though? Because then
> it's included on the default interceptor stack.
>
> Unfortunately it's expected until the old file upload interceptor is
> removed from the default interceptor stack in Struts 7.0. It can't be
> removed in Struts 6.7 as applications that have yet to migrate to the
> new file upload interceptor flow would stop working (breaking change).
> The log warning is inconsequential though and can be easily suppressed
> by renaming the name attribute on your s:file tag.
>
> On Mon, Nov 11, 2024 at 7:16 PM Greg Huber<[email protected]> wrote:
>> Definitely do not have <interceptor-ref name="fileUpload" /> in my
>> struts.xml
>>
>> but this in my jsp: <s:file name="uploadedFiles" size="95"
>> multiple="multiple" />
>>
>>
>> If "name" on  s:file matches a private field (no getters/setters) in my
>> action I get the warning. ie
>>
>> jsp:
>>
>> <s:file name="uploadedFilesz" size="95" multiple="multiple" />
>>
>> action class :
>>
>> private List<UploadedFile> uploadedFilesz = null;
>>
>> 2024-11-11 08:05:18,083 WARN
>> com.opensymphony.xwork2.ognl.SecurityMemberAccess
>> SecurityMemberAccess:isAccessible - Access to non-public [private
>> java.util.List my.Upload.uploadedFilesz] is blocked!
>>
>> Is this what is expected?
>>
>> On 10/11/2024 11:31, Kusal Kithul-Godage wrote:
>>> If you're able to dump a stack trace for the log warning using the
>>> debugger I can probably check further.
>>>
>>> But if I had to guess (and I may very well be wrong here) you're using
>>> one of the default interceptor stacks that includes both the old and
>>> new file upload interceptors and you've also got s:file tags using the
>>> name 'uploadedFiles'. If this is the case, the old file upload
>>> interceptor will attempt injection using OGNL. The easiest way to
>>> suppress the warning is your current workaround of changing the field
>>> name, or change the name on your tag(s).
>>>
>>> On Sun, Nov 10, 2024 at 8:41 PM Greg Huber<[email protected]> wrote:
>>>> I just upgraded to the UploadedFilesAware version and now I see this
>>>> message in my logs
>>>>
>>>> WARN com.opensymphony.xwork2.ognl.SecurityMemberAccess
>>>> SecurityMemberAccess:isAccessible - Access to non-public [private
>>>> java.util.List my.MyUpload.uploadedFiles] is blocked!
>>>>
>>>> Every thing is working ok.
>>>>
>>>> In MyUpload I have declared this:
>>>>
>>>> private List<UploadedFile> uploadedFiles = null;
>>>>
>>>> There is no reference I can find outside the class that uses this
>>>> variable.  There is no setter/getter either.
>>>>
>>>> As a test I renamed it in the class:
>>>>
>>>> private List<UploadedFile> uploadedFilesz = null;
>>>>
>>>> which should make no difference as I implement the withUploadedFile method:
>>>>
>>>> public void withUploadedFiles(List<UploadedFile> uploadedFiles) {
>>>>
>>>>            this.uploadedFilesz = uploadedFiles;
>>>>
>>>>        }
>>>>
>>>> The message goes away. So I have to not use the variable name
>>>> uploadedFiles in my class ???
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:[email protected]
>>> For additional commands, e-mail:[email protected]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:[email protected]
>> For additional commands, e-mail:[email protected]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:[email protected]
> For additional commands, e-mail:[email protected]
>