[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    Re: AliasInterceptor parameter mapping issue
From:       Brian Lenz <brian () socialstrata ! com>
Date:       2020-08-28 15:57:23
Message-ID: CAFEoLj+2AONeQwvsxAqC_A4RvJPN9tJs_XLvqWxUs4LGPmFWxA () mail ! gmail ! com
[Download RAW message or body]


Thanks for the response, Yasser! Sure thing, I've created the bug here:

https://issues.apache.org/jira/browse/WW-5087

Best,

Brian

On Fri, Aug 28, 2020 at 8:56 AM Yasser Zamani <yasserzamani@apache.org>
wrote:

> Hi Brian,
> 
> Sorry for inconvenience :( yes for me as well it looks like an
> unintentional bug introduced by [1].
> 
> Thanks a lot for writing to us! To followup its resolution would you
> mind create a new JIRA ticket?
> 
> Regards.
> 
> [1]
> 
> https://github.com/apache/struts/commit/787f2f96eb9f1bb3c8012ab42aa222ae6286a91a#diff-b7b7c87c1012088e79dcc5a7bd9e8127
>  
> On 8/28/2020 4:58 AM, Brian Lenz wrote:
> > Hello,
> > 
> > We are running into an issue with the AliasInterceptor after upgrading to
> > 2.5.22 (from 2.3.35). The issue is that the fallback behavior to look in
> > HttpParameters for a value guarantees a value will always be set and that
> > Evaluated.isDefined() will subsequently always return true. The issue is
> > that HttpParameters.get() *always* returns a non-null value. If there
> isn't
> > an explicit value set, then it returns a Parameter.Empty. This cascades
> > back to AliasInterceptor, which results in the empty value *always* being
> > set on the stack.
> > 
> > As an example, let's say I have a parameter f with alias foo. If I set a
> > value for foo on the request, the behavior in AliasInterceptor will
> result
> > in an empty value being set for foo, thus overwriting the actual value
> > submitted.
> > 
> > Is this the designed behavior? Based on the structure of the code, it
> > appears to be a bug since there is unnecessary logic otherwise
> > (specifically, the call to value.isDefined() on line 179). Further, this
> is
> > different behavior from the older versions of Struts
> (pre-HttpParameters).
> > 
> > Instead, I would think that isDefined() should be checked on the
> > Parameter returned
> > from HttpParameters so that a non-null value is only set in the
> Evaluated if
> > the parameter is actually defined.
> > 
> > Does anyone have any thoughts or insight into this issue? I looked in
> JIRA
> > and couldn't find anything related to it. Does anyone know of any
> > workarounds (aside from creating a custom AliasInterceptor to fix the
> > behavior)?
> > 
> > Thanks!
> > 
> > Brian
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]