The Google One-Tap Sign-Up documentation web page displays the following message:
This API is currently in closed beta. We are improving the API's cross-browser functionality and will provide updates here in the coming months.
https://developers.google.com/identity/one-tap/web/
Is One-Tap Sign-Up safe for production use currently?
Also while testing the functionality I was not able to test this on non-Chrome browsers successfully. Is this available for browsers other than Chrome?
was also looking for a clear answer to this
from troubleshooting page:
...If you see the warning The client origin is not permitted to use this API, your service has not yet been accepted to the beta. New sign-ups to this beta are currently closed.
They also have a supported browser \ os table on there
Related
I am trying to automate login to my app which uses among others, google sso authentication.
However login form return error "This browser or app may not be secure.". I set my google account options to allow less secure apps but still nothing.
I browsed few topics:
GMail is blocking login via Automation (Selenium)
Selenium Google Login Block
Automation Google login with python and selenium shows ""This browser or app may be not secure""
And it seems that google is blocking this way at all in favor of oauth.
People write in these topics that solutions stopped working recently
So is it currently possible, to set ChromeDriver somehow using capabalities, to be able to login through SSO?. I need a simple solution, that will run headless with other scripts on cloud (not something that would require me to manually login first on another instance as one anwser suggests).
If its not possible or extremly complicated please tell me I will not waste time on it.
If you want to use chrome capabilities, what you can do is set the user-data-dir to a chrome profile that has already been signed in using SSO.
You should look up how to reuse chrome profiles with selenium.
If your accounts have 2 steps verifications, google believe it's safer and allows you to get login. Then the issue will be how to handle the 2 steps verifications. Working on that :/
I have already asked this question on CEF Forum https://www.magpcss.org/ceforum/viewtopic.php?f=10&t=18006. But unfortunately still haven't received an answer to my question.
According to the https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html Google will apply OAuth2 for sing-in since January 4, 2021.
I have tried to test my CEF app for compatibility with OAuth2 according to "Test for compatibility" section from here https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html.
When I navigated to https://accounts.google.com/ I simply added Google-Accounts-Check-OAuth-Login:true header to CefRequest in CefResourceRequestHandler.OnBeforeResourceLoad (like described in "Test for compatibility") but nothing has changed, I still could login successfully to google account via CEF browser. After that I opened CEF browser's DevTools via Remote debugging port to check via Network tab the headers of http requests. But the result was that Google-Accounts-Check-OAuth-Login:true header has been added successfully to http requests.
So how should I simulate the case that CEF app is considered to be insecure because CEF app is not using OAuth2, when logging in to https://accounts.google.com/?
Thank you in advance
I'm curious how reCAPTCHA v3 works. Specifically the browser fingerprinting.
When I launch an instance of Chrome through Selenium/chromedriver and test against reCAPTCHA 3 (https://recaptcha-demo.appspot.com/recaptcha-v3-request-scores.php) I always get a score of 0.1 when using Selenium/chromedriver.
When using incognito with a normal instance, I get 0.3.
I've beaten other detection systems by injecting JavaScript and modifying the web driver object and recompiling webdriver from source and modifying the $cdc_ variables.
I can see what looks like some obfuscated POST back to the server, so I'm going to start digging there.
What might it be looking for to determine if I'm running Selenium/chromedriver?
reCaptcha
Websites can easily detect the network traffic and identify your program as a BOT. Google have already released 5(five) reCAPTCHA to choose from when creating a new site. While four of them are active and reCAPTCHA v1 being shutdown.
reCAPTCHA versions and types
reCAPTCHA v3 (verify requests with a score): reCAPTCHA v3 allows you to verify if an interaction is legitimate without any user interaction. It is a pure JavaScript API returning a score, giving you the ability to take action in the context of your site: for instance requiring additional factors of authentication, sending a post to moderation, or throttling bots that may be scraping content.
reCAPTCHA v2 - "I'm not a robot" Checkbox: The "I'm not a robot" Checkbox requires the user to click a checkbox indicating the user is not a robot. This will either pass the user immediately (with No CAPTCHA) or challenge them to validate whether or not they are human. This is the simplest option to integrate with and only requires two lines of HTML to render the checkbox.
reCAPTCHA v2 - Invisible reCAPTCHA badge: The invisible reCAPTCHA badge does not require the user to click on a checkbox, instead it is invoked directly when the user clicks on an existing button on your site or can be invoked via a JavaScript API call. The integration requires a JavaScript callback when reCAPTCHA verification is complete. By default only the most suspicious traffic will be prompted to solve a captcha. To alter this behavior edit your site security preference under advanced settings.
reCAPTCHA v2 - Android: The reCAPTCHA Android library is part of the Google Play services SafetyNet APIs. This library provides native Android APIs that you can integrate directly into an app. You should set up Google Play services in your app and connect to the GoogleApiClient before invoking the reCAPTCHA API. This will either pass the user through immediately (without a CAPTCHA prompt) or challenge them to validate whether they are human.
reCAPTCHA v1: reCAPTCHA v1 has been shut down since March 2018.
Solution
However there are some generic approaches to avoid getting detected while web-scraping:
The first and foremost attribute a website can determine your script/program is through your monitor size. So it is recommended not to use the conventional Viewport.
If you need to send multiple requests to a website keep on changing the User Agent on each request. Here you can find a detailed discussion on Way to change Google Chrome user agent in Selenium?
To simulate human like behavior you may require to slow down the script execution even beyond WebDriverWait and expected_conditions inducing time.sleep(secs). Here you can find a detailed discussion on How to sleep webdriver in python for milliseconds
Outro
Some food for thought:
Selenium webdriver: Modifying navigator.webdriver flag to prevent selenium detection
Unable to use Selenium to automate Chase site login
Confidence Score of the request using reCAPTCHA v3 API
Selenium and Puppeteer have some browser configurations that is different from a non-automated browser. Also, since some JavaScript functions are injected into browser to manipulate elements, you need to create some override to avoid detections.
There are some good articles explaining some points about Selenium and Puppeteer detection while it runs on a site with detection mechanisms:
Detecting Chrome headless, new techniques - You can use it to write defensive code for your bot.
It is not possible to detect and block Google Chrome headless - it explains in a clear and sound way the differences that JavaScript code can detect between a browser launched by automated software and a real one, and also how to fake it.
GitHub - headless-cat-n-mouse - Example using Puppeteer + Python to avoid detection
I'm using W3C Browser Web Speech Api. I search everywhere but i cant find it answer. Is there any limitation for usage ?
Demostration: https://www.google.com/intl/en/chrome/demos/speech.html
Yes, with a bit of a catch. I finally hit a limit recently after a lot of experimentation; as soon as a request starts, it's cut short.
On a desktop web browser (Chrome), there's a limit for each user (Primiano Tucci works at Google, so I'd trust him!), and you can't buy more time with the API.
However, as you could see from the first link, the exception appears to be Chrome on Android, which apparently has no limitations because it accesses an internal API for speech recognition when visiting web pages that use the Web Speech API.
For desktop browsers, you're out of luck unless you can assume users don't mind a limit. Even Annyang and voice dictation in Google Docs aren't working for me at the moment, while online voice recognition services that don't go through Google are working.
From my testing with Chrome Version 87.0.4280.141 (Official Build) (64-bit), it appears to stop after 5 minutes on Windows 10 Pro.
Recently, AuthSub died...?
Is it possible to migration from session_token of Authsub to refresh_token of OAuth2 ?
Please tell me how to do it if possible.
Its still supported, but is failing for us as well (and others if search twitter for it). I'm wondering if Google is experience a technical issue with AuthSub or if they made a change (e.g. patch/release) earlier this week that is causing the issues?
We see it working for some Google accounts and fail for others - starting on Dec 10/11. So, its not impacting every Google account.
We are currently not capturing the outgoing requests to google. We are using the library gdata-calendar-1.0.jar to make google calendar api calls using AuthSub and the library is throwing an exception with the exception message "Unknown authorization header". This worked perfectly up until Dec 10/11th or so for all of our users.
What is strange is now the same calls do work for certain gmail accounts but not for others.
In our testing we are seeing that turning off the enhanced security in our web application results in the warning displayed to the user on the Google Authorization page but makes the connection work for the accounts that are failing.
Here are the api calls we are making:
AuthSubUtil.exchangeForSessionToken to connect to the google account
CalendarService.query to get events
CalendarService.insert to insert events in calendar
CalendarService.getFeed to get the calendars
AuthSub is still supported by Google as per Google's deprecation policy.
As for a migration path to OAuth2, currently there is none.