After lot of problems i finally got liferay sign in through jmeter work. But it only worked twice. First with one user in the thread group. And then i used 10 users out of which 3 were successfully logged in. So it means my way of doing it has no problem (since it was successful on 4 occasions). But next time onward, it stopped working. Only suspicious observation I have is all the requests are getting same auth token (p_auth) no matter how many times or how many users i run it with. I even restarted jmeter. Why would it generate the same token consistently for all different requests through jmeter? When i try a browser, it works (comes with different token every time).
How do I get it to working? Any help is appreciated!
Liferay introduces a token (p_auth) for CSRF protection. This token can be used just once, and that's a problem for performance tests.
You should disable that token during the tests execution, but remember to enable it again after the tests.
auth.token.check.enabled=false
Related
while executing script on jmeter getting token session expired error showing in below image, searched on google and tried to solve,it is not solved
Most probably you recorded the test using HTTP(S) Test Script Recorder and the token which is used for authentication purposes has limited time to live so once it has expired it cannot be used anymore.
As your application suggests you need to perform the login process once again, then extract the token using a suitable Post-Processor, save it into a JMeter Variable and replace recorded value with the variable from the previous step.
The whole process of handling dynamic parameters is known as correlation and there is a lot of information on the topic in the Internet with examples.
Maybe I searched with the wrong keywords but I never found anything about the following scenario:
I have both an API with JWT auth (Laravel + tymon/jwt-auth) and a PHP application that should query that API protected by a JWT token.
How can I make sure that the app always is authentificated? After reading a lot of tutorials and article about JWT auth I'm left with this ideas:
using a never expiring token which is stored permanently in the consuming application. If I understand it right this could be a security concern because someone who has access to that token has access to the api as long as he want? But I don't understand why this token shouldn't be invalidated if the token has been stolen?
refresh the token on every request and invalidate the old one. This implies that the consuming application have to update the token after each request in it's storage (database would make the most sense, I guess). In my opinion this produces a lot of overhead and it doesn't prevent for jwt-auth's refresh_ttl setting.
using an additional API request (perhabs cron based?) to a refresh route to prevent the token from expiring. Again there is the jwt-auth's refresh_ttl problem I think.
I wonder why there seems to be no discussions/articles about that scenario.
Any help on that subject I would very much welcome!
You don't want your user logging in every time but you also don't want them to be logged forever.
Here are my thoughts
I have worked with 1 year tokens for comercial applications, I was using it for low level third party developers, the api concept was already overwhelming for them so I went easy on the auth thingy. Once every year their application broke and they had to reach out to get the new token, bad design but it worked.
Refreshing your token on every request will kill your performance and let attackers have a consistent way to break/predict your key, no good.
In my opinion, this is your most elegant suggestion. You could use some PWA features to accomplish that.
I would suggest increasing the refresh_ttl to 30 days and keep the ttl on one hour.
If you're using SPA or heavy js apps:
On your javascript you could do an ajax setup (or prototype or whatever your javascript framework uses for oop) and have a call to refresh whenever you get a .
If you're using just common page refresh for your apps, store you JWT on a cookie, then your application can refresh it whenever it needs and there will be no special js to make. HTTPS will take care of security.
I have an application hosted in Azure using Azure Active Directory and OpenIDConnect for authentication - generally all works well. However I'm having an issue where some requests generate a call to https://login.microsoftonline.com/ and then on to the requested page - no password is requested. I'm assuming that this is some kind of token refresh?
The problem is that the site uses a fair amount of ajax and these requests stop working because they get redirected to https://login.microsoftonline.com/ This happens after maybe 15 minutes, however the nbf and exp properties of the JWT token show a validity period of approximately an hour.
I've set the BackchannelTimeout property of OpenIdConnectAuthenticationOptions to 30 minutes, however this doesn't seem to have made any difference.
Can anyone offer any advice on what may be happening and the options to change or work around the behaviour?
Your question can be answered in the same way as this other thread: MVC AD Azure Refresh Token via ADAL JavaScript Ajax and KnockoutJs
In short: the OpenId Connect middleware is designed to support redirect based web applications. Ajax calls are not well suited to be protected via cookies, and the issue you are experiencing is one of the reasons why. Javascript based API calls are better protected using tokens rather than cookies.
For some links that might provide an alternative approach, see the link above.
I created a nuget package for .NET web applications which is refreshing the Azure Active Directory Token in the background.
More info: https://www.nuget.org/packages/RefreshTokenForAjaxRequest.Azure.ActiveDirectory/
I have been using a plain old vanilla Thread Group in JMeter for a while now, using a Once Only Controller to authenticate each thread before accessing the page in my app I wish to profile.
This has been working perfectly. However I now want to try using a Stepping Thread Group with my app so I tried this same approach but it's not working - when I look at the results of the main request for the page I am trying to profile, I can see it's instead redirecting to the login screen, since the thread is not logged in.
I then got rid of the Once Only Controller and tried to simply have 2 requests under the Stepping Thread Group - first one to simply login, then a separate request to hit my app page to profile. However I'm running into the same issue (even though it does appear the login request is being executed - I'm seeing correct responses and activity there in the View Results listener, so maybe it's just not happening in the correct order?).
Sorry if I'm missing something, I'm still relatively new to JMeter. Any help or guidance greatly appreciated. Thanks!
Turns out I was missing an HTTP Cookie Manager. Though interestingly some of the responses for the page I wish to profile are coming back to the Login page as unauthenticated but most are making it through now.
Can someone explain to me how to get jmeter to login. I have an http request that goes to apps/j_security_check. I have added two parameters j_username and j_password. It does not seem to authenticate the user when I run this request.
I found what was wrong. I used a Capital J in j_password causing the authentication to fail.
Thanks for every bodies help.
Take a gander at simulate 200 users with jmeter, each with unique logins
It may be that to login you must pass a unique security token.
Have you tried recording the login process, to see what is captured?
If you add a "View Results Tree" you should see the exact login error.