I have a script that is logging in and navigating to a different page. Sometimes this works but some time it doesn't. I am unable to pin point the reasons. I have tokens taken care of. When it does not run properly it is redirecting to the login page. I can see the tokens are properly used until this point but I cannot figure it out why it is throwing the page back at login.
Can someone help me resolving this please?
Related
I have recorded script for atlassian confluence system. Purpose of this recording is to perform load test on confluence. Below scenarios are recorded
Login
Browse a Space
Create a wiki page
Edit a wiki page
Commenting on page
Logout
I have modified the script and those scenarios are worked fine when i run the script. Then when i record the script again and did the same modifications the edit action is not working as before. I have tried page editing action on multiple environments and sometimes it works and all the time it's not works. Why this is happening?
This is very high level information that you have shared. Please share more info about what kind error do you get in case of failures. You might be able to trace down your problem & solution by looking into following points.
Is your login request successful (valid login session)
Are you using cookie manager
Have you used assertions to verify valid/invalid responses
Have you used debug sampler and View Tree Results listener
Please use above to narrow down your problem and then share it over here.
This is a very strange one for me and I've been battling with it for a while now. I really hope someone can help.
I have a fairly typical MVC 3 Website and I only seem to be getting this problem in IE and Firefox. Chrome plays along nicely. Lucky for me, the majority of our company's clients uses Chrome at the moment.
Problem is at a seemingly random point in time, the browser will automatically redirect me to the Account/LogOff action when I click on a link, and from there it will obviously go back to the Login page. This link will then continue with the same behavior.
I say "seemingly random" because today that link will work, tomorrow it won't and all other (or the majority - I have never had more than on problem link giving this problem at a time) links will be fine. Sometimes restarting the server/dev environment will take care of the problem, other times it won't. The browser will just keep redirecting to LogOff.
I have tried looking at the Referrer URL, but the controller/action being referred to will never be reached. (If I place a breakpoint in the action, it is missed and the next point reached would be the LogOff action)
If I look at the stacktrace when in the LogOff Action, I can't see any info from where the application has come from. I have also tried what was suggested in this page: Posting the Stack Trace on ASP.NET MVC, but I cannot see why I am being redirected to the LogOff action.
The only place I seem to be able to have a breakpoint get hit before hitting LogOff, is Application_BeginRequest in the Global.asax, but can't see where it is going from there on.
My guess is that somewhere along the line, ASPNET Auth decides the user isn't authenticated any more and redirects to the LogOff action. Problem is that the cookies associated with ASPNET Auth all still exist, have data in them and they haven't expired yet.
Anyway, I hope I have given enough info on the problem.
Thanks in advance.
[Edit]
OK, so I might have gotten a step closer. I came across this link and looked to see what is happening in my Application_AuthenticateRequest in my global.asax.
I am not quite sure why, by when I click on a link, Application_AuthenticateRequest gets accessed 3 times. When a link works (as in I can follow it and it doesn't log me out), the value of the .ASPAUTH cookie stays the same. I checked this by adding a breakpoint and a watch over
HttpContext.Current.Request.Cookies[".ASPXAUTH"].Value
When the link does not work, the first time the cookie has a value, then the other two times it is null. Thus, because the ASPXAUTH cookie is null, the system automatically redirects to the LogOut action.
If I consider the solution they posted in the link, I am not sure if this applies to me. As far as I can tell, the encrypted cookie is still small (as in a few hundred characters long) and not close to 4096 bytes. Also, I have only 3 cookies going at the time I when tested the broken link and I have a maximum of 5 cookies at any given time.
Any idea?
OK, so I had a hunch about cookies expiring. So I looked at whether there is a way to keep (force) cookies in Forms Authentication alive and that led me to http://www.codeproject.com/Articles/221889/How-to-Generate-Machine-Key-in-IIS7
The only way I could test this theory was to keep working and debugging the site as normal. (And that's why it took me so long to post this answer.) Since I introduced this solution it seems that the problem has been solved.
Interestingly I spoke an Architect the other day, with 20 years dev experience, about my problem. He looked at my code and is convinced this is a bug in the Forms Authentication code.
I hope this helps some people who are experiencing the same problem I have.
We are having an issue with logging in a second time on our site ever since we installed the lightspeed module. At first I thought this might have to do with the need for hole punching, but now I'm not sure.
If you try to log into our website the first time, it works well. However, if you log in a second time, it won't work. It just remains on the customer/account/login page with no effect.
I tried to test this on my end, and echoed the user's email in the loginPost function in the account controller. When echoing directly from the controller, it was obvious that the user was being logged in, but upon the redirect to a page on the site, the user was no longer logged in and appeared as a Guest in the Magento backend (where you view online customers).
It appears to me as if the session is being lost after the redirect. I am not sure if this has anything to do with a switch between https and http as described in the stackoverflow problem here (http://stackoverflow.com/questions/7823994/magento-session-lost-when-switching-to-https-from-http ) where they had also installed lightspeed. The person there resolved the problem, but did not post the solution. Their problem wasn't the same as ours, but I was thinking there may be a connection between the two.
Has anyone seen a problem like this before?
Thanks in advance,
Brenda
Trying to load test a site using a tool i dont quite understand against a formatting standard I cant seem to crack. so:
somesite.com/users/sign_in/service:accounts?redirect=/
is the url in question. While I (think) I understand what this url is doing, what are my steps to test in jmeter?
Any help appreciated.
The steps to test in Jmeter depend largely on what you're trying to test.
As a starting point, I would recommend recording logging into the site, so you capture every parameter that's being sent along with its value.
You can then parametrize these values as needed. It looks like once someone logs in, they get redirected to another page. Mostly likely when you record, you'll see the login page and then a landing page captured.
I was hoping someone could shine some light on my problem. I am in the process of load testing a website. For authenticity, I would like to simulate users logging in and such. JMeter refuses to comply. I have tried manually using HTTPS requests, HTTPS spoofing that is provided, and exporting login scripts from Badboy. Using the View Results Tree listener after running a test, it seems that everything is working, but in the end I am always redirected to the login page. The cookie appears to be functioning properly as it displays the same session for each request.
Thanks in advance for any wisdom you all may offer.
While badboy is a great tool to create jmeter test in https.
But on our apps, badboy seem to add get request that didn't work at all, I had to remove them manually to fix the problem.
And if you have a token or session id in your cookies, it's doesn't take care of it for you so you got to figure out how to extract them with a reg-ex extrator and put in a variable that your test will use.
These problem were very specific to our apps not sure it apply to you, but if you remove unessary request and take care of sending back your token/session id it might do the trick.
I was facing the similar issue sometime ago but since my web application was JSF based I had to take care of the javax.faces.ViewState.
In my case every response had a JFV and I had to pass it as a parameter to the next request using Regular Expression Extractor.
Kindly check if your application is having any such problem.
Regards