You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Prasanth Pasala <pp...@pangburngroup.com> on 2018/04/16 14:49:52 UTC
Re: Struts2 login action class seems to be reused
Finally we redeployed the code with an added check to make sure the instance variables populated by struts match the request parameters. With in few hours of deployments we got emails indicating that
the values populated into the instance variables don't match those in request parameters. Below you can see the difference between the instance variable and the values in the request object. The code
is also updated to store the hash code of Login action for each login, so that we can see if the object is reused. Surprisingly the hash code doesn't match with any of the hash codes stored for
successful logins. When the emails are triggered there is only a GET request for the Login action (which should display the login page, on the user enters the username & password it is submitted via
POST). So I am wondering where did these values come from into the instance variables?
-----------------------------------------------------------------
Struts data doesn't match that in request object.
Struts Data:
Username: jsmith
Action: Login
Request Data:
Username: null
Action: null
Object Hash: 1573857416
-----------------------------------------------------------------
Thanks,
Prasanth
On 03/16/2018 02:30 PM, Prasanth Pasala wrote:
> There is only one reference to Util.authenticate in the project and that is in LoginAction.
>
> On 03/16/2018 02:13 PM, Yasser Zamani wrote:
>> And you confirm that those log record insertions are only possible via LoginAction.execute method? Right? Or util.authenticate are called elsewhere also?
>> On Mar 16, 2018, at 9:45PM, Prasanth Pasala <pp...@pangburngroup.com>> wrote:
>>
>> We have a pretty standard struts.xml just declaration of action and the class along with the results (tiles results). Nothing other than that.
>>
>> On 03/16/2018 11:55 AM, Yasser Zamani wrote:
>>
>> On 3/16/2018 1:49 AM, Prasanth Pasala wrote:
>> We do have login time, using that and the IP to correlate that with the access logs. Not all login entries have corresponding POST entries in access log, so those would be our problems occurrences.
>> They actual correspond to a GET entry from a user.
>>
>> IP of the GET request of User1 matches with the login record in the database (login would be for User2 id and IP from User1 GET). So it looks as if the same user logged in from two different IPs
>> around the same time, which shouldn't be the case.
>> I'm almost sure Struts always asks object factory to create the action
>> on each request. This is belong to object factory if create a new one
>> object of that action, or no, reuse a previous one object of an action.
>> So have you set any specific object factory via struts.xml?
>>
>> ________________________________
>>
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 5/15/2018 12:45 AM, Prasanth Pasala wrote:
> A different issue is coming up now after the get methods are removed. Getting the below exception some times when you request the login page, at which point the browser doesn't have the session id
> yet, the session id mentioned would be a session id from a previous request (from another thread, in JMeter testing). Wonder if, some how this data (session id) is also moved by struts2 when copying
> data from the other LoginAction that is lingering from old requests.
>
> Thanks,
> Prasanth
>
> Exception: java.lang.IllegalStateException: UT000010: Session is invalid JVoo5BkMlzTpOavsEe7_NjS0MzTXDlhYtlSviiGR
AFAIK session is completely managed by browser and app server e.g.
tomcat; So I think this isn't a Struts issue.
Regards.
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
A different issue is coming up now after the get methods are removed. Getting the below exception some times when you request the login page, at which point the browser doesn't have the session id
yet, the session id mentioned would be a session id from a previous request (from another thread, in JMeter testing). Wonder if, some how this data (session id) is also moved by struts2 when copying
data from the other LoginAction that is lingering from old requests.
Thanks,
Prasanth
Exception: java.lang.IllegalStateException: UT000010: Session is invalid JVoo5BkMlzTpOavsEe7_NjS0MzTXDlhYtlSviiGR
On 04/24/2018 09:00 AM, Prasanth Pasala wrote:
> I have removed the get methods from the LoginAction of /Context2 and that seems to solve the problem. So seems like the LoginAction objects created because of FORWARD some how are in the stack while a
> LoginAction is created due to a REQUEST. Wondering if this can be replicated without having two contexts. If there is a FORWARD within the context and the same action can also be initiated by direct
> REQUEST wonder if the same issue will crop up.
>
> Thanks,
> Prasanth
>
> On 04/24/2018 01:52 AM, Yasser Zamani wrote:
>> On 4/23/2018 11:50 PM, Prasanth Pasala wrote:
>>> Get rid of the get methods in LoginAction, is this in /Context2 (application where the issue is occurring) or /Context1 (which forwards the requests to /Context2)?
>>>
>> That contexts who forwards request (Context1 I think) but you may do for
>> all to be sure. However, I still prefer rewriting FORWARD with REDIRECT
>> or POSTBACK to prevent future possible issues.
>>
>>> Yes exactly. The new log shows, your previous contexts actions
>>> (LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
>>> current context because you forward same request which includes previous
>>> context data, then, Struts ChainInterceptor copies data from previous to
>>> current action :S . As currently Struts cannot handle forwarded requests
>>> well, could you please try REDIRECT instead? sendRedirect asks user
>>> browser to continue with a new request.
>>>
>>> Still not sure about the above comment. So the ChainInterceptor is getting data from an action that occurred before and is not part of current request?
>> Struts has a stack. ChainResult push current action to stack for next
>> action. In next action, ChainInterceptor pops it and copies values. Now
>> you have two actions in stack (I don't know how but seems it's because
>> of forward same request which has previous context1 stack) and
>> ChainInterceptor thinks ChainResult has pushed that and then pops and
>> copies them into current action.
>>
>> Regards.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
I have removed the get methods from the LoginAction of /Context2 and that seems to solve the problem. So seems like the LoginAction objects created because of FORWARD some how are in the stack while a
LoginAction is created due to a REQUEST. Wondering if this can be replicated without having two contexts. If there is a FORWARD within the context and the same action can also be initiated by direct
REQUEST wonder if the same issue will crop up.
Thanks,
Prasanth
On 04/24/2018 01:52 AM, Yasser Zamani wrote:
>
> On 4/23/2018 11:50 PM, Prasanth Pasala wrote:
>> Get rid of the get methods in LoginAction, is this in /Context2 (application where the issue is occurring) or /Context1 (which forwards the requests to /Context2)?
>>
> That contexts who forwards request (Context1 I think) but you may do for
> all to be sure. However, I still prefer rewriting FORWARD with REDIRECT
> or POSTBACK to prevent future possible issues.
>
>> Yes exactly. The new log shows, your previous contexts actions
>> (LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
>> current context because you forward same request which includes previous
>> context data, then, Struts ChainInterceptor copies data from previous to
>> current action :S . As currently Struts cannot handle forwarded requests
>> well, could you please try REDIRECT instead? sendRedirect asks user
>> browser to continue with a new request.
>>
>> Still not sure about the above comment. So the ChainInterceptor is getting data from an action that occurred before and is not part of current request?
> Struts has a stack. ChainResult push current action to stack for next
> action. In next action, ChainInterceptor pops it and copies values. Now
> you have two actions in stack (I don't know how but seems it's because
> of forward same request which has previous context1 stack) and
> ChainInterceptor thinks ChainResult has pushed that and then pops and
> copies them into current action.
>
> Regards.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/23/2018 11:50 PM, Prasanth Pasala wrote:
> Get rid of the get methods in LoginAction, is this in /Context2 (application where the issue is occurring) or /Context1 (which forwards the requests to /Context2)?
>
That contexts who forwards request (Context1 I think) but you may do for
all to be sure. However, I still prefer rewriting FORWARD with REDIRECT
or POSTBACK to prevent future possible issues.
>
> Yes exactly. The new log shows, your previous contexts actions
> (LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
> current context because you forward same request which includes previous
> context data, then, Struts ChainInterceptor copies data from previous to
> current action :S . As currently Struts cannot handle forwarded requests
> well, could you please try REDIRECT instead? sendRedirect asks user
> browser to continue with a new request.
>
> Still not sure about the above comment. So the ChainInterceptor is getting data from an action that occurred before and is not part of current request?
Struts has a stack. ChainResult push current action to stack for next
action. In next action, ChainInterceptor pops it and copies values. Now
you have two actions in stack (I don't know how but seems it's because
of forward same request which has previous context1 stack) and
ChainInterceptor thinks ChainResult has pushed that and then pops and
copies them into current action.
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
Get rid of the get methods in LoginAction, is this in /Context2 (application where the issue is occurring) or /Context1 (which forwards the requests to /Context2)?
Yes exactly. The new log shows, your previous contexts actions
(LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
current context because you forward same request which includes previous
context data, then, Struts ChainInterceptor copies data from previous to
current action :S . As currently Struts cannot handle forwarded requests
well, could you please try REDIRECT instead? sendRedirect asks user
browser to continue with a new request.
Still not sure about the above comment. So the ChainInterceptor is getting data from an action that occurred before and is not part of current request?
Thanks,
Prasanth
On 04/23/2018 01:27 PM, Yasser Zamani wrote:
>
> On 4/23/2018 10:12 PM, Prasanth Pasala wrote:
>> The user is inputting username and password in /Context1, if I send a redirect they would have to enter username/password again in /Context2.
>>
> No, you already have them. I think you can use Struts PostbackResult [1]
> in /Context1/LoginAction like below:
>
> <result type="postback">/Context2/LoginAction</result>
>
>> May be for LoginAction in /Context2 I can remove instance variables (so that struts doesn't set any values) I will directly access the request object to get username and password to validate.
> The simpler solution is deleting getUsername and getPassword methods
> from LoginAction which disables ChainInterceptor to copies them and
> solves this issue! But I'm worry about other issues caused by FORWARD,
> so please try replacing all of them as I mentioned above.
>
> [1] https://struts.apache.org/core-developers/postback-result.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/23/2018 10:12 PM, Prasanth Pasala wrote:
> The user is inputting username and password in /Context1, if I send a redirect they would have to enter username/password again in /Context2.
>
No, you already have them. I think you can use Struts PostbackResult [1]
in /Context1/LoginAction like below:
<result type="postback">/Context2/LoginAction</result>
> May be for LoginAction in /Context2 I can remove instance variables (so that struts doesn't set any values) I will directly access the request object to get username and password to validate.
The simpler solution is deleting getUsername and getPassword methods
from LoginAction which disables ChainInterceptor to copies them and
solves this issue! But I'm worry about other issues caused by FORWARD,
so please try replacing all of them as I mentioned above.
[1] https://struts.apache.org/core-developers/postback-result.html
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
The two LoginAction classes below are from the same context (/Context2). Context1 LoginAction would have a different package name. The issue occurs when a user is requesting /Context2 directly rather
than when the request is forwarded, if the request is forwarded from /Context1 it would have the username and password in the request and those seems to be working fine. The issue is when there are
requests forwarded from /Context1 with username and password and later on there is a GET request to /Context2 LoginAction (no username/password in request, so should display login page). Now some how
struts is using data from the old forwarded requests (sent from Context1) for a request made directly to Context2.
The user is inputting username and password in /Context1, if I send a redirect they would have to enter username/password again in /Context2.
May be for LoginAction in /Context2 I can remove instance variables (so that struts doesn't set any values) I will directly access the request object to get username and password to validate.
Thanks,
Prasanth
On 04/23/2018 12:31 PM, Yasser Zamani wrote:
>
> On 4/23/2018 8:04 PM, Prasanth Pasala wrote:
>> Found this one also but for almost all, the root size was 3. Below one was anomaly.
>> Root Size: 4
>> Result: null
>> Object: com.opensymphony.xwork2.DefaultTextProvider@4d36d73d
>> Object: com.nqadmin.webaccess.LoginAction@7f716c46
>> Object: com.nqadmin.webaccess.LoginAction@35224c2f
>>
>> Also found that the issue doesn't come up if I am logging in only to the second website (/context2). The issue only comes up if there are users logging in via context1, whose login request is
>> forwarded to context2.
> Yes exactly. The new log shows, your previous contexts actions
> (LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
> current context because you forward same request which includes previous
> context data, then, Struts ChainInterceptor copies data from previous to
> current action :S . As currently Struts cannot handle forwarded requests
> well, could you please try REDIRECT instead? sendRedirect asks user
> browser to continue with a new request.
>
> Regards.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/23/2018 8:04 PM, Prasanth Pasala wrote:
> Found this one also but for almost all, the root size was 3. Below one was anomaly.
> Root Size: 4
> Result: null
> Object: com.opensymphony.xwork2.DefaultTextProvider@4d36d73d
> Object: com.nqadmin.webaccess.LoginAction@7f716c46
> Object: com.nqadmin.webaccess.LoginAction@35224c2f
>
> Also found that the issue doesn't come up if I am logging in only to the second website (/context2). The issue only comes up if there are users logging in via context1, whose login request is
> forwarded to context2.
Yes exactly. The new log shows, your previous contexts actions
(LoginAction@7f716c46 and LoginAction@35224c2f) are also present in
current context because you forward same request which includes previous
context data, then, Struts ChainInterceptor copies data from previous to
current action :S . As currently Struts cannot handle forwarded requests
well, could you please try REDIRECT instead? sendRedirect asks user
browser to continue with a new request.
Regards.
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
Found this one also but for almost all, the root size was 3. Below one was anomaly.
Root Size: 4
Result: null
Object: com.opensymphony.xwork2.DefaultTextProvider@4d36d73d
Object: com.nqadmin.webaccess.LoginAction@7f716c46
Object: com.nqadmin.webaccess.LoginAction@35224c2f
Also found that the issue doesn't come up if I am logging in only to the second website (/context2). The issue only comes up if there are users logging in via context1, whose login request is
forwarded to context2.
Since it have been a while including the details of how our setup works.
Context 2 & Context 3 are two websites and depending on user type they have to login to one or the other. To make it easy for the user we have Context1 where we allow users to login this site checks
the database and determines which site they need to be logging into and forwards the login request to Context2 or Context3. We have users who would login to the right context and some who utilize
Context1 to login.
Thanks,
Prasanth
On 04/23/2018 09:42 AM, Prasanth Pasala wrote:
> Below is the result of the new logging.
>
> Root Size: 3
> Result: null
> Object: com.opensymphony.xwork2.DefaultTextProvider@4d36d73d
> Object: com.xxxxxx.webaccess.LoginAction@40c80ce8
>
> Thanks,
> Prasanth
>
> On 04/21/2018 05:09 AM, Yasser Zamani wrote:
>> On 4/19/2018 4:39 PM, Prasanth Pasala wrote:
>>> There is a index.jsp which is defined as default page in web.xml it just forwards the request to Login.action. There is no chaining of actions in struts itself. We do have a LoginFilter which verifies
>>> if a user is logged in.
>>>
>> So maybe there is a bug with chain interceptor! Could you please use
>> following code in your action setUsername method (save it's log in a
>> private string field in your action). Then print it when your action
>> data are not consistent with request params.
>>
>> String log = "";
>> ActionInvocation invocation= ActionContext.getActionInvocation();
>> ValueStack stack = invocation.getStack();
>> CompoundRoot root = stack.getRoot();
>> log += "Root Size: " + root.size();
>> Result result = invocation.getResult();
>> log += "\r\nResult: " + result;
>> List list = new ArrayList(root);
>> list.remove(0);
>> Collections.reverse(list);
>> for (Object object : list) {
>> log += "\r\nObject: " + object;
>> }
>> this.log = log; //saves for possible future use
>>
>> Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
Below is the result of the new logging.
Root Size: 3
Result: null
Object: com.opensymphony.xwork2.DefaultTextProvider@4d36d73d
Object: com.xxxxxx.webaccess.LoginAction@40c80ce8
Thanks,
Prasanth
On 04/21/2018 05:09 AM, Yasser Zamani wrote:
>
> On 4/19/2018 4:39 PM, Prasanth Pasala wrote:
>> There is a index.jsp which is defined as default page in web.xml it just forwards the request to Login.action. There is no chaining of actions in struts itself. We do have a LoginFilter which verifies
>> if a user is logged in.
>>
> So maybe there is a bug with chain interceptor! Could you please use
> following code in your action setUsername method (save it's log in a
> private string field in your action). Then print it when your action
> data are not consistent with request params.
>
> String log = "";
> ActionInvocation invocation= ActionContext.getActionInvocation();
> ValueStack stack = invocation.getStack();
> CompoundRoot root = stack.getRoot();
> log += "Root Size: " + root.size();
> Result result = invocation.getResult();
> log += "\r\nResult: " + result;
> List list = new ArrayList(root);
> list.remove(0);
> Collections.reverse(list);
> for (Object object : list) {
> log += "\r\nObject: " + object;
> }
> this.log = log; //saves for possible future use
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/19/2018 4:39 PM, Prasanth Pasala wrote:
> There is a index.jsp which is defined as default page in web.xml it just forwards the request to Login.action. There is no chaining of actions in struts itself. We do have a LoginFilter which verifies
> if a user is logged in.
>
So maybe there is a bug with chain interceptor! Could you please use
following code in your action setUsername method (save it's log in a
private string field in your action). Then print it when your action
data are not consistent with request params.
String log = "";
ActionInvocation invocation= ActionContext.getActionInvocation();
ValueStack stack = invocation.getStack();
CompoundRoot root = stack.getRoot();
log += "Root Size: " + root.size();
Result result = invocation.getResult();
log += "\r\nResult: " + result;
List list = new ArrayList(root);
list.remove(0);
Collections.reverse(list);
for (Object object : list) {
log += "\r\nObject: " + object;
}
this.log = log; //saves for possible future use
Thanks!
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
There is a index.jsp which is defined as default page in web.xml it just forwards the request to Login.action. There is no chaining of actions in struts itself. We do have a LoginFilter which verifies
if a user is logged in.
Thanks,
Prasanth
On 04/19/2018 03:26 AM, Yasser Zamani wrote:
>
> On 4/19/2018 7:21 AM, Prasanth Pasala wrote:
>> com.opensymphony.xwork2.interceptor.ChainingInterceptor.copyStack(ChainingInterceptor.java:153)
>> com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:143)
> Thanks! These lines show Struts doesn't set username from a request
> parameter, but it seems that you have a chain result to login action
> which sets username from it's previous action's getUsername! Could you
> verify these via reviewing your struts.xml finding an action that has a
> chain result to login action?
>
> Thanks in advance!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/19/2018 7:21 AM, Prasanth Pasala wrote:
> com.opensymphony.xwork2.interceptor.ChainingInterceptor.copyStack(ChainingInterceptor.java:153)
> com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:143)
Thanks! These lines show Struts doesn't set username from a request
parameter, but it seems that you have a chain result to login action
which sets username from it's previous action's getUsername! Could you
verify these via reviewing your struts.xml finding an action that has a
chain result to login action?
Thanks in advance!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts2 login action class seems to be reused
Posted by Prasanth Pasala <pp...@pangburngroup.com>.
Below is the stack trace for setting of username. So struts2 has set the username, but that name doesn't exist in the request object.
Struts Data: Username: jsmith Action: Login
Request Data: Username: null Action: null
java.lang.Thread.getStackTrace(Thread.java:1559)
com.xxxxx.webaccess.LoginAction.setUsername(LoginAction.java:273)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:897)
ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:1299)
ognl.OgnlRuntime.setMethodValue(OgnlRuntime.java:1508)
ognl.ObjectPropertyAccessor.setPossibleProperty(ObjectPropertyAccessor.java:85)
ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:162)
com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:27)
ognl.OgnlRuntime.setProperty(OgnlRuntime.java:2437)
ognl.ASTProperty.setValueBody(ASTProperty.java:127)
ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220)
ognl.SimpleNode.setValue(SimpleNode.java:301)
ognl.Ognl.setValue(Ognl.java:713)
com.opensymphony.xwork2.ognl.OgnlUtil$6.execute(OgnlUtil.java:504)
com.opensymphony.xwork2.ognl.OgnlUtil$6.execute(OgnlUtil.java:501)
com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:393)
com.opensymphony.xwork2.ognl.OgnlUtil.copy(OgnlUtil.java:501)
com.opensymphony.xwork2.ognl.OgnlReflectionProvider.copy(OgnlReflectionProvider.java:73)
com.opensymphony.xwork2.interceptor.ChainingInterceptor.copyStack(ChainingInterceptor.java:153)
com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:143)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:171)
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:140)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:193)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:189)
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:245)
org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54)
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:575)
org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:81)
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
com.xxxxx.webaccess.LoginFilter.doFilter(LoginFilter.java:52)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209)
io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:221)
io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147)
io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111)
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:722)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:695)
org.apache.jsp.index_jsp._jspService(index_jsp.java:107)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)
Thanks,
Prasanth
On 04/17/2018 10:28 AM, Yasser Zamani wrote:
>
> On 4/16/2018 7:19 PM, Prasanth Pasala wrote:
>> So I am wondering where did these values come from into the instance variables?
> Great! Please also get the current stack trace inside your action's
> setUsername method and save it in a private string field inside your
> action. Then when action and request data mismatched, also print this
> string which answers where did these values come from.
>
> Thanks in advance!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
Re: Struts2 login action class seems to be reused
Posted by Yasser Zamani <ya...@apache.org>.
On 4/16/2018 7:19 PM, Prasanth Pasala wrote:
> So I am wondering where did these values come from into the instance variables?
Great! Please also get the current stack trace inside your action's
setUsername method and save it in a private string field inside your
action. Then when action and request data mismatched, also print this
string which answers where did these values come from.
Thanks in advance!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org