A web app that I'm trying to login with htmlunit is expecting all cookie key/value on a single Cookie request header.
All searches on this topic ends with a link that supposedly has a workaround. http://htmlunit.sourceforge.net/phpwiki/index.php/SingleCookieHeader but the link is now dead.
Anyone know how to solve this problem? Or has a cached copy of the above mentioned link?
Also found a patch here http://sourceforge.net/p/htmlunit/feature-requests/72/ describing the problem but the patch itself never made it into htmlunit's build.
You can extract the cookies you need by calling
Set<Cookie> cookies = webClient.getCookieManager().getCookies();
and you can construct a custom request and send the cookies as a single request header.
Related
I would like to start by saying that I have gone through several answers on related topics here and none seems to fix my issue.
I have created a new thread group and added a new header manager and cookie manager to it. I have 3 https requests in the thread group. The first call is an authentication call which needs no cookies. This call returns 3 cookies in response headers that I need to pass for further requests.
Authentication call is working fine. But the calls after authentication is not working since the cookies are not set. I have added 'CookieManager.check.cookies=false' to the user.properties file and still seeing '[no cookies]' in all requests. I have also tried adding a dummy cookie to the cookie manager under 'User-Defined Cookies' section as shown in the screenshot and even that cookie is not added to the requests.I am getting '[no cookies]' in all requests.
I have also tried all options under policy manager like standard, compatible etc without any success. Also tried this in Jmeter 3.1 and 3.3 (latest version) and the same issue observed.
Any suggestions or solutions are highly appreciated.
To add a custom cookie you must set its Domain to your application domain, otherwise it will not be picked up
Your Path should start with a forward slash / and need to match the request URL path , however it is better to remove anything from that input
It might be the case you're suffering from Bug 56358 so consider upgrading to JMeter 3.3, it can resolve your issue
As a last resort you can always fetch cookies you need from the Set-Cookie response header using Regular Expression Extractor
You could also try going the dirty way and get the cookies values from the previous response and use them in the following parameters or store it. You can do this using a Post processor - Regular Expression Extractor that you put in the first Authentication request. Here is a site that explains how to use RegEx https://octoperf.com/blog/2017/09/07/jmeter-regular-expression-extractor/
I am attempting to scrape the source data of a particular URL using ruby. To begin, I am using Net::http.new to create the http object and then using http.post to pass along the appropriate login data. This works as intended and responds with the appropriate session cookies.
After logging in, and adding the session cookie data to the headers, I then try to access the particular page that I want to scrape. The server responds with a 302 request to an aspx URL on a different subdomain, accompanied with a query string ie. sub.domain.com/path/blah.aspx?md5=jdj456bnn. When I try to load that subdomain using the same technique as I used before, I am met with a user not authorized 302. does anyone know the proper way to load that relocation, or what I could be missing here?
It's very possible a session cookie is being set during the redirect, but your code isn't maintaining it.
"net-http-cheat-sheet" might show how to deal with it, or, look into using Mechanize, which will manage them for you using a cookie jar.
I see that google or twitter autosuggest's sends ajax requests which are very lightweight since they don't send any cookies with the request. I was wondering how do they do it?
I googled about ways but i found ways like sending via CORS but they are sending the request to the same domain.
Any idea or ways on how to do that.
I am using chrome.
Thanks in advance
These are the two options I can think of to answer your question:
Option 1: Set withCredentials: false when using XMLHttpRequest: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
Option 2: Delete cookies before sending the request and (in the case of wanted re-use restore them afterwards from temp variable) like so:
Get cookies and store them somewhere (f.i. in global var)
Delete cookies from domain
Send AJAX request
Restore cookies from variable
I'm developing an iOS app that makes frequent requests to a web server, and I'm using AFNetworking (which I very much like). However, I'm running into a problem with authorization that I just can't solve.
The server requires me to provide an authorization header in order to get the response that I want. Specifically, the authorization headers should be like so:
Authorization = "ApiKey some-user-name:someNumericalApiKey"
I'm using AFNetworking throughout the project, and everything works fine, except for this authorization issue. I'm using the following code:
[myClient setDefaultHeader:#"Authorization" value:#"ApiKey some-user-name:someNumericalApiKey"];
where myClient points to an AFHTTPClient object. Strange enough, when I log the request in XCode using AFHTTPRequestOperationLogger, the logger claims that I have the correct headers set. However, the authorization header does not seem to reach the server - I can't see it in the server log.
To isolate the problem, I've tried to make the exact same request using good old NSURLRequest, as well as curl, and the requests library in Python - all of these work fine, i.e. the authorization header is sent & received (i.e. I can see it in the server log), and the server response is what it should be.
If anyone has run into the same problem (and has found a solution) I would very much appreciate to hear from you.
Thanks.
Sometimes (especially with Django) this is caused by redirection stripping of header parameters. For instance, /Object redirects to /Object/ in the background and removes the necessary auth parameter during the switch.
If you're using AFNetworkActivityLogger with level AFLoggerLevelDebug then you should be able to check this out in the console. If you see a POST request with /Object and the response with /Object/ then this might indicate redirection stripping is taking place.
If you construct your operation manually then the defaultHeaders are not applied, that might be the cause of your problem.
As the title may possibly suggest, I'm wondering what's more secure for AJAX requests: POST or GET. I can't work out which is better because they're both hidden from the user due to the URI being sent via. AJAX, not in the URL bar.
Thanks,
James
Neither add any security against either man-in-the-middle attacks or the end user. Both can be intercepted and tampered with using Wireshark, Firebug, or other tools.
If you want security against interception, you can use HTTPS. That does not prevent the user from sending requests manually, though.
It's almost trivially easy to inspect the contents of both post and get values. Your best bet, if you do not want the user to be able to get at that data directly, is to encrypt it, and / or send it over ssl.
There are no security differences between POST and GET used in AJAX. They are not hidden from the user - a simple tool like Fiddler would allow the user to see those requests. the payload in both is in plain text (ie, as your script created it). The only difference is that POST payload is in the body of the request and GET payload is in the query params of the URL.
They are not hidden from the user at all; install FireBug on FireFox and they are able to see the URI. Your choice of using GET and POST depends on the data sent; and if you going by REST standards, depending on the operation.
Treat an AJAX call as you would with information coming from the client through a form and through the address bar : Verify and sanctify.
They can view the page source and see where your target URL is and what parameters are being passed either way.