I'm using jmeter to load test a Feature Page.
My jmeter requests (for that page) are being redirected to a login page. How do I provide login info for that redirect?
I already tried:
Controller
Login Page
Feature Page
Logout
But somehow a user even though already authenticated via Login Page is still being asked to login on the Feature Page.
Wondering if someone has a suggestion.
Make sure you're really logged in as "green" result in JMeter doesn't necessarily indicates successful request. You can verify responses using View Results Tree
listener
Add HTTP Cookie Manager to your Test Plan, if your application uses cookies for establishing/maintaining user session it should automatically resolve your problem
Inspect your test plan for any dynamic values (request parameters, headers, URL postfixes, etc.), if the are - they need to be correlated.
Related
I am facing one problem that i am unable to login to the liferay website using JMeter.
The problem i know already but don't know how to hanmdle it.
I get to know that "p_auth" token is requried to access the sub pages, but here i am facing an issue in which i don't even able to acccess the login page itself if run the script second time.
My concerns:
how to check "p_auth" token parameter for login page (i.e without login)
Please help me to solve the problem.
Note: i tried to extract the "p_auth" token , but i am unable to see any "p_auth" token for login page itself(i.e without login.. just a login page(get api))
Your test plan need to look like:
Open Login Page - HTTP GET request
Extract p_auth dynamic parameter value using a suitable JMeter Post-Processor
Perform the login - HTTP POST request where you need to provide your credentials and the p_auth token value from the previous request
You won't be able to "see" the token in the page, it's hidden in the page source so you will need to use browser developer tools or JMeter's View Results Tree listener in order to "see" the token value.
Also don't forget to add HTTP Cookie Manager to your test plan as missing CSRF token is not the only thing which can stop you from logging in.
Currently, I’m developing a web app with server-side rendering using the Gin framework and I’m having a problem with login intercepting. When an HTTP GET request hits an endpoint, middleware is used to check the browser cookie and redirect the traffic to the login page. This works fine and after successful login, the user is always redirected to the dashboard page. My question is how I should redirect the user back to the originally requested URI instead of the dashboard page?
Also, a bit more complex scenario is on HTTP POST. It looks like the HTTP POST method doesn’t work quite well with a redirect. Also, how would I resume the request with the same post request after the user successfully login?
Thanks for the help!
For the HTTP GET scenario, this one is easy, you need to remember the original URL somewhere. The are a few ways you could go about this:
Store the URL in session information(if any is available, you do need sessions for non-authenticated users)
Store it in a query string, for example, redirect to example.com/login?original=https%3A%2F%2Fexample.com%2Fanother-page. Your login page can look for the query parameter and include it in the login form or make sure that the action of the login form matches the given URI. On a successful login attempt you can get the original URL form the query param and set it as the Location.
Store the original URL in a cookie, upon successful login you can just check the cookie value and use that.
As for the HTTP POST scenario. If you just want to redirect the same POST request to a different URL you can use a 307 Temporary redirect. A 307 will preserve the request body and method and not turn it into a GET request like a 303 See Other or 302 Found.
Resuming the original POST after showing the login screen and after a successful login is a little more complex. When you redirect to the login page you interrupt the flow of the user, maybe it is better to let the user re-post their request after logging in, instead of doing it for them.
Having said that, it is technically possible. We require two steps, first is storing all the data to recreate the request. Then after login completion we can render a form with this saved data and use javascript to submit the form. By adding:
<script>document.getElementById("myForm").submit();</script>
After your form, the browser will submit the form after loading the javascript, thus recreating the original POST.
The storage part can be done via the server side session or a cookie.
I created a script multiple user logins and redirected to the home page. For multiple user logins fetching data from CSV file but after logged in, home page redirection is not working.
There are multiple possible explanations:
Your login fails somewhere somehow so you're still at the login page, check the server response using View Results Tree listener and if this is the case - fix your script. It might be sufficient to add a HTTP Cookie Manager to represent user session
You might need to play with Redirect automatically / Follow redirects checkboxes on HTTP Request sampler level
Your redirect is being managed by JavaScript and JMeter is not capable of executing JavaScript so you need to extract the desired redirect location using a suitable JMeter Post-Processor (basically implement correlation of the redirect URL) and add another HTTP Request sampler to open the redirect target.
More information: Redirections in HTTP
In general make sure that JMeter sends the same requests as the real browser does, given this simple rule is met you should be able to properly simulate real user actions
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
I am running spring web application in broswer. I logged in to my account and update some value using a url say localhost:80/update/name. On the controller side I check principal==null if not redirect to login page.
Now while login to this application. I open other web application page in the same browser and execute the same update url localhost:80/update/name through ajax call and it is updating the value. How can i avoid this security threat.
How can i make sure that Application1 update url will be executed by application1 request only? Application2 should not be allowed to execute app1's update request no matter whether it is in same browser ?
Why are you surprised ? You are logged, thus the browser has a valid session cookie. You ask the browser to send a request to the host (be it in first window or any other window, it is the same) : it sends the request with all relevant cookies, including session cookie and if appropriate any other security cookie. The server receives a request containing a valid session cookie for a valid logged user and even if it controls IP addressed coming from same address : all is valid and it proceeds with the request.
If you have a different browser on your client machine and if you open the connection from this unrelated browser, the server should reject your request, because the browser would not present a valid cookie.
You are describing a variant of cross-site request forgery, you should enable Spring Security CSRF protection. You can read about it in the reference manual.
Even if the two applications are on the same server, they will get different CSRF tokens, which will protect your case.
You described Cross-Site request forgery attack. Typically when POST method is used hidden token is added to prevent it. I assume You are using GET method - It is good practice to not change any state using GET method.