留言板
JMeter login
Dear colleagues,
Im trying to create a JMeter test plan, simulating a logon using a recorded request and awaiting an appropriate response. While doing so, I noticed since liferay portal seems to be a J2EE engine, the initial response is containing a jsessionid cookie, which I was aware and it seems due given Jmeter cookie handling this value is forwarded to following requests, so the authentication should work in generally.
However, this is not the case, Im not getting a valid logon resp the response data Im expecting while running such a JMeter test. I was pointed on stackoverflow to avoid CSRF liferay portal uses p_auth, which I can see on the initial request for login as a parameter and I should focus on, since jsessionid doesnt seems to by my problem.
Following that clue I cant recognize a comprehensible logic in handling the p_auth parameter: following the architecture of known CSRF avoiding implementations, I would expect the server delivering this value within a response answering a client request and using it in following traffic. Due the browser record Im using for a login request this is not the case, the parameter is delivered on a initial login request:
-> I would like to provide a screenshot, but for reasons I dont understand I cant upload a screenshot, but should provide a public url instead, what I ofcourse cant do for my private resources. Im attaching it on the thread instead
However, p_auth is not coming up in following measured traffic at all, neither in requests nor in responses. Possibly my assumption is wrong and I dont need it at all, but Im running out of clues: what is the reason my simulated login is denied? If anybody knows how the authentication with record / replay network traffic can be done, Im would be glad about a hint. Thank you,
best regards
Im trying to create a JMeter test plan, simulating a logon using a recorded request and awaiting an appropriate response. While doing so, I noticed since liferay portal seems to be a J2EE engine, the initial response is containing a jsessionid cookie, which I was aware and it seems due given Jmeter cookie handling this value is forwarded to following requests, so the authentication should work in generally.
However, this is not the case, Im not getting a valid logon resp the response data Im expecting while running such a JMeter test. I was pointed on stackoverflow to avoid CSRF liferay portal uses p_auth, which I can see on the initial request for login as a parameter and I should focus on, since jsessionid doesnt seems to by my problem.
Following that clue I cant recognize a comprehensible logic in handling the p_auth parameter: following the architecture of known CSRF avoiding implementations, I would expect the server delivering this value within a response answering a client request and using it in following traffic. Due the browser record Im using for a login request this is not the case, the parameter is delivered on a initial login request:
-> I would like to provide a screenshot, but for reasons I dont understand I cant upload a screenshot, but should provide a public url instead, what I ofcourse cant do for my private resources. Im attaching it on the thread instead
However, p_auth is not coming up in following measured traffic at all, neither in requests nor in responses. Possibly my assumption is wrong and I dont need it at all, but Im running out of clues: what is the reason my simulated login is denied? If anybody knows how the authentication with record / replay network traffic can be done, Im would be glad about a hint. Thank you,
best regards
附件:
Btw, as Im reading right now, the current runtime behaviour on the customer system is thereby purposeful contrary to liferay technical documentation as far I understood this:
https://web.liferay.com/de/community/wiki/-/wiki/Main/Authentication+Token
"...Is implemented to prevent Cross Site Request forgery, as explained here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
This token is included in every action request in the portal including the "p_auth" parameter in URL..."
https://web.liferay.com/de/community/wiki/-/wiki/Main/Authentication+Token
"...Is implemented to prevent Cross Site Request forgery, as explained here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
This token is included in every action request in the portal including the "p_auth" parameter in URL..."
As my colleagues indicated, the sentence
"...This token is included in every action request..."
was not interpreted by myself correctly. liferay uses a quite strange proprietary concept for distinguishing requests (action, render, http obviously) that can be send to the AS - so my expectation p_auth will used in every request is simply wrong, since the login request is an action request, but the following rendering requests are not. So at the end it should be enough to fill a form in JMeter, the question if p_auth will be used in following depends on what you want to do
best regards
"...This token is included in every action request..."
was not interpreted by myself correctly. liferay uses a quite strange proprietary concept for distinguishing requests (action, render, http obviously) that can be send to the AS - so my expectation p_auth will used in every request is simply wrong, since the login request is an action request, but the following rendering requests are not. So at the end it should be enough to fill a form in JMeter, the question if p_auth will be used in following depends on what you want to do
best regards