I am trying to simulate the login process of a website that has invisible recaptcha using Postman. I used both chrome DevTools and interceptor feature of the Postman. I also used the capture cookies feature in Postman to ensure I have the same cookies as in Chrome. The POST request for login api of the website has a JSON body of something like below:
{"userName":"myusermane","password":"mypassword","captchaResponse":"03AGdBq25SXrvrLWv3VbhyNPYCccO62Scf5reo04IeLNloKGo7ND1TcX7mg67fG-tL_0w1E7urn0MvoCJvdl6c5SBDloPXaeHiTnDMsjIgEGrvLjPbdsZ8U6vpL8VuqX1DZgGFRXXj_97ra1ZgYpuQykxnCEtgXQXwVqF5IbHyGj7MwtzM0jvT1wHdfFCDDJ3o9Z7edgUfHZeHHjfmMI_s1j5wZY2Lvp9XEGYdA9kmR5kZxu_CaGZ9i9rll8nY-GBqC4wWNuazB0l9F7k3R0ragTL9eoNawsdUP2l8nBvpR0dhWf476KqBgN7fE7aIj6HNQbCzRltgiUJeUh5RUmZk_XeUdN2hNhTAhfK8cwH1crn-bddCQ9J4ZJtFOcZ8qTYZbf6PWp1Hw8lX"}
The problem is while the login is successful in Chrome, the exact same request in Postman fails. Why is this happening? I am thinking that there might be something with invisible recaptcha fundamental that I do not understand. Hope someone can figure it out
The problem is while the login is successful in Chrome, the exact same request in Postman fails. Why is this happening?
This is the purpose of a Captcha: it prevents automated logins, allowing only a human to log in.
In other words, this is happening because it is exactly what is supposed to be happening.
Related
Using OkHttp3 I was happily scraping a website for quite some time now. However, some components of the website have been upgraded and are now using an additional OpenID bearer authentication.
I am 99.9% positive my requests are failing due to this bearer token because when I check with Chrome dev tools, I see the bearer token popping up only for these parts. Moreover, a couple of requests request are going to links that end with ".well-known/openid-configuration". In addition, when I hardcode the bearer token from my browser in my OkHttp3 code, everything works. Without the code, I get an 401 non authorized message.
I figured that my browser emulation was not close enough to the real situation so I decided to use a headless browser setup that is doing some javascript invocations. Since I am using Java, I used HtmlUnit. Using this tool I could quickly get to the point where I could successfully scrape parts of the website (just as with OkHttp3) but it would again fail with the newly updated parts. I checked but couldn't find the bearer token in any of the responses (nor in the headers or in the cookies).
Is there any chance this approach (using a headless browser) could work? Or are there perhaps alternative approaches I could check.
I have written a multiplayer game using Libgdx and I would like to add a facebook login option. On the server side, I am using NodeJS and PassportJS to validate requests. So far I am able to send and receive HTTP requests using Libgdx's HttpRequest and HttpResponseListener.
My question is, is Libgdx able to display an http response in a way that a browser would? If not, I don't see how user will be able to confirm facebook permissions since I cannot show them the response they get from the facebook. I would greatly appreciate if someone can tell me how this would work. (As far as I know, nodejs redirects user to a facebook page, so I will be getting an http content to my code in Libgdx)
Note: I aim to use the application both in ios android and desktop.
I am trying to obtain token for my UCWA app using passive auth. My setup is that once I receive the 401 challenge, I take the link to the token service from ms_rtc_passiveauthuri parameter and I visit this website (PassiveAuth.aspx) by creating a hidden iframe in the background of my website. Couple of redirects happen in that iframe but eventually I successfuly get the cookie and I proceed with creating the UCWA app.
This works nicely in IE, Chrome, Firefox and Opera, but Safari seems to refuse to do this redirections inside of that iframe.
I also tried to visit this token service by using the XFrame (and using helper library's Transport.clientRequest), but the result is 406 Not Acceptable.
Do you know about any workaround for Safari? Or, more importantly, is my approach correct - is this how it's meant to be used?
Thanks for any suggestion
Did you manage to work this out? I am having the same issues.
Edit : See the comments below for the answer - look out for the WWW-Authenticate and Www-Authenticate headers.
I want to automate logging into a website and retrieving certain data.
I thought the way to do this would be to sniff the HTTP requests so I know where the login form is being POSTed to so I can do the same using NodeJS/Java/Python.
However I can't seem to find the HTTP request that handles it.
The site seems to use some Java-applet and a lot of Javascript.
This is the site: link
Should I have a different approach?
Also also wonder about storing a cookie session, and sending it with each HTTP request after logging in.
I'm sorry if I am not to clear, I will try to explain myself further and edit this post if needed.
You can use the developer console (hit F12) in Chrome (this works also in other browsers) and then click the "Network" tab. There you see all network calls.
To detect what http requests are performed from a mobile device, you can use a proxy like Charles Proxy.
Also be aware that if you post from nodejs the cookies won't be set in the users browser.
I am looking for a website that requires HTTP authentication, so I can observe the behaviour of typical HTTP authentication dialog boxes. The reason I am looking into this, is that for some reason, on Firefox 3, our Flex app seems to open another HTTP authentication dialog box again, after cancel is clicked. It only seems to happen in Firefox 3. I want to find out if this is just a Firefox 3 issue, the nature of HTTP authentication, or something is wrong with our Flex app.
EDIT: I should clarify some more details. The problem with our flex app, is that when the authentication dialog box appears, the user clicks cancel. Then attempts to enter the page again, causing the authentication dialog box to appear again. However, if they type the correct password, the same dialog will reappear.
Thanks,
Jason
This website offers an example of HTTP authentication: http://www.httpwatch.com/httpgallery/authentication/
Firefox doesn't seem to realize that when you enter a username and password for a site it should attempt that authentication on all subsequent frames before asking you to log in again.
I'm not sure why this is, it seems like a bug to me but perhaps there is good reason for it.
One way to get around it is to begin your site on a page without frames, once HTTP authentication is finished redirect them to the framed page.