I need a help, I try to record a script of some application like http://in.musafir.com/ ,https://www.makemytrip.com/ etc but after recording started page is open but CSS not apply in that case I am unable to create script due to fields missing or disturbance.
I am not excluding CSS and other in JMeter proxy server page.
One another thing some application getting connection exception after used ApacheJMeterTemporaryRootCA (its apply in the case show the message) .
This all testing is done in home environment & company environment. And both places has same issue.
Please update me the solution of this issues.
JMeter HTTPS script recorder gives you option to exclude certain URL requests based on their type. You can add or remove these URL patterns in your HTTPS Test Script Recorder.
JMeter recording template by default excludes css. So if you want to record CSS requests then simply remove css from this section. Check screenshot for details.
Regarding Root Certificate, if you are getting a message like below then it is normal and expected.
Please read JMeter Official documentation for more details about HTTP Test Script Recorder.
Related
I tried to record a site using JMeter which uses Firebase for data storage but it fails to access the firebase and I can not log into the site while recording. Is there any way to access firebase during the recording of load testing in JMeter? I entered the JMeter certificate also but still, the problem is there. And also tried using the chrome extension still it also didn't give the expected output Error Description Image
Most probably it's due to incorrect JMeter configuration for recording, you need to import JMeter's certificate into your browser. The file is called ApacheJMeterTemporaryRootCA.crt, JMeter generates it under its "bin" folder when you start the HTTP(S) Test Script Recorder.
See HTTPS recording and certificates documentation chapter for more details.
Going forward consider looking at View Results Tree listener output and jmeter.log file, they should provide sufficient amount of information in order to get to the bottom of the issue. If you cannot interpret what you see there yourself - add at least essential parts of response/log to your question.
Also be aware of alternative "non-invasive" way of recording a JMeter test - JMeter Chrome Extension, in that case you won't have to worry about proxies and certificates and should be able to normally record whatever HTTP(S) traffic your browser generates
I'm wondering if anyone else has had this issue with Azure Front Door and the Azure Web Application Firewall and has a solution.
The WAF is blocking simple GET requests to our ASP.NET web application. The rule that is being triggered is DefaultRuleSet-1.0-SQLI-942440 SQL Comment Sequence Detected.
The only place that I can find an sql comment sequence is in the .AspNet.ApplicationCookie as per this truncated example: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH. If I remove the 2 dashes '--' in the cookie value, the request successfully gets through the firewall. As soon as I add them back the request gets blocked by the same firewall rule.
It seems that I have 2 options. Disable the rule (or change it from Block to Log) which I don't want to do, or change the .AspNet.ApplicationCookie value to ensure that it does not contain any text that would trigger a firewall rule. The cookie is generated by the Microsoft.Owin.Security.Cookies library and I'm not sure if I can change how it is generated.
I ran into same problem as well.
If you have a look to the cookie value: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH there are two -- which is the potentially dangerous SQL command that can comment out your SQL command that you're going to query. An attacker may run their command instead of your command - after commenting out your query.
But, obviously, this cookie won't run any query on the SQL side and we are sure about that. So we can create rule exclusions that won't run specific conditions.
Go to your WAF > Click Managed Rules on the left blade > Click manage exclusions on the top > and click add
In your case, adding this rule would be fine:
Match variable: Request cookie name
Operator: Starts With
Selector: .AspNet.ApplicationCookie
However, I use Asp.Net Core 3.1 and I use Asp.Net Core Identity. I encountered other issues as well, such as __RequestVerificationToken.
Here is my full list of exclusions. I hope it helps.
PS I think there is a glitch at the moment. If you have an IP restriction on your environment, such as UAT, because of these exclusions Web Application Firewall is by-passing the IP restriction and your UAT site becomes open to the public even if you have still custom IP restriction rule on your WAF.
I ran into something similar and blogged about it here: Front Door incomplete first request.
To test this I created a web application and put it behind the Front Door service. In that test application I iterate over all the properties of the HttpContext.HttpRequest and print them out. As far as I can see right now, there are two properties that have differences between a direct request and a request through Front Door. Both the AcceptTypes and the UserLanguages property are empty for Front Door requests, while they are absolutely filled in when directly accessing the test application.
I’m not quite sure what the reason is for the first Front Door request to be different from a direct request. Is it a bug? Is it intentional and if so, why? Or is it because Front Door is developed using a framework that doesn’t support these properties, having them be empty when being forwarded?
Unfortunately I didn't find a solution to the issue, but to answer the question if anyone else is experiencing this: I did experience something similar.
Seems that the cookie got corrupted , as I was comparing the fields that existed before vs a healthy cookie, my guess is maybe somewhere in the content of the field it is being interpreted as a truncate sql statement and probably triggering the rule. Still to determine if this is true and/or what cause it.
I ran into this issue but the token was being passed through via the request query rather than via a cookie. In case it might help someone, for the specified host I had to allow via a custom rule doing a regex match on the RequestUri, using the following regex (taken from the original managed rule):
:\/\\\\*!?|\\\\*\/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|--[^-]*?-|[^\\u0026-]#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00
I have a test plan for our UAT environment using JMeter and part of the user journey involves hitting a page with an iframe to accept payment using a payment provider.
The payment provider from the iframe has three stages:
Select payment type (VISA, MasterCard etc.)
Enter payment details (Card number, expiry etc.)
Enter status code (Approved or Declined because it is a test environment)
How do I implement these iframe requests using JMeter?
You can try and record it first. Use either JMeter proxy: http://jmeter.apache.org/usermanual/component_reference.html#HTTP(S)_Test_Script_Recorder
Or BlazeMeter's Chrome extension: http://community.blazemeter.com/knowledgebase/articles/231479-chrome-extension
You will then need to clean an parametrize your script. Take a look at CSV data set config: http://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config
If you need some video tutorials to do just that, take a look here: http://blazemeter.com/blog/jmeter-tutorial-video-series
You're best bet is probably BlazeMeter's JMeter chrome extension, though you need to change one of the settings.
When you are browsing a site that uses iframes, AJAX calls, JS based requests (etc) you need to into the "Advanced Options" in the extension and uncheck "Record Only Top Level Requests".
The extension will now record EVERY request your browser is making, so be sure to close any other tabs you have open.
The Test Script Recorder might be failing due to security issues on the domain in the iframe. The advantage of using the chrome extension is that it doesn't care if the requests are secure or not.
Hi
I've downloaded the Cairngorm3 Simple Sample Application from here.
There's a few steps.
a) Download the server-side zip. It contains a PDF instructing how to start a HSQLDB database and get a Tomcat instance up an running (I used catalina.sh start).
b) Check out the source with Subversion, and load it up into Flashbuilder 4. (You need Flex 3.4 SDK)
When I run the app (an Outlook like app written in Flex), I have issues at the point I try and save a contact. I'm assuming it's on a remoteobject call.
But it I get this:
Send failed
faultCode:Client.Error.MessageSend faultString:'Send failed' faultDetail:'Channel.Ping.Failed error Detected duplicate HTTP-based FlexSessions, generally due to the remote host disabling session cookies. Session cookies must be enabled to manage the client connection correctly. url: 'http://localhost:8400/messagebroker/amf;jsessionid=5765DDDB6E2D54BD03D3E636B0E8C03E'''
I'm wondering if this is something you need to tweak in services-config.xml?
Located in flex-frameworks/tomcat/webapps/ROOT/WEB-INF/flex folder (flex-frameworks comes from the server-side zip download:
Anyone got any ideas?
This is Christophe Coenraets baby.
I also subsequently found a blog post by Alexander Glosband, but couldn't ascertain from it, what you need to do as a work around. i.e. Is this something that is configurable?
The way to reproduce the error consistently is to try and activate the web camera from the app. Then instead of clicking accept, reload the screen. Then when you try and take a photo after subsequently granting access to camera, you get the duplicate session error.
I think there is an issue with the code pertaining to the Camera, that's not cleaning up after itself correctly, the session is probably not being tidied up correctly.
You are right, problem comes from services-config.xml. Change your url from
http://localhost:8400/messagebroker/amf
to
/messagebroker/amf
I found solution from here send failed error
"Compiler EMBEDS channels, endpoints and destinations into SWF" video tells.
I have a dynamically generated rss feed that is about 150M in size (don't ask)
The problem is that it keeps crapping out sporadically and there is no way to monitor it without downloading the entire feed to get a 200 status. Pingdom times out on it and returns a 'down' error.
So my question is, how do I check that this thing is up and running
What type of web server, and server side coding platform are you using (if any)? Is any of the content coming from a backend system/database to the web tier?
Are you sure the problem is not with the client code accessing the file? Most clients have timeouts and downloading large files over the internet can be a problem depending on how the server behaves. That is why file download utilities track progress and download in chunks.
It is also possible that other load on the web server or the number of users is impacting server. If you have little memory available and certain servers then it may not be able to server that size of file to many users. You should review how the server is sending the file and make sure it is chunking it up.
I would recommend that you do a HEAD request to check that the URL is accessible and that the server is responding at minimum. The next step might be to setup your download test inside or very close to the data center hosting the file to monitor further. This may reduce cost and is going to reduce interference.
Found an online tool that does what I needed
http://wasitup.com uses head requests so it doesn't time out waiting to download the whole 150MB file.
Thanks for the help BrianLy!
Looks like pingdom does not support the head request. I've put in a feature request, but who knows.
I hacked this capability into mon for now (mon is a nice compromise between paying someone else to monitor and doing everything yourself). I have switched entirely to https so I modified the https monitor to do it. The did it the dead-simple way: copied the https.monitor file, called it https.head.monitor. In the new monitor file I changed the line that says (you might also want to update the function name and the place where that's called):
get_https to head_https
Now in mon.cf you can call a head request:
monitor https.head.monitor -u /path/to/file