I maintain an application written in C++Builder 2009. Part of it involves using a TWebBrowser control (based on Internet Explorer) to send users to a Google login page in order to obtain an OAuth key. This has worked well for a while, but now Google, bless their hearts, has implemented some kind of security upgrade, and now my users get to a page that says "Couldn't sign you in, this browser or app may not be secure". FYI, I am already setting a Registry key that is supposed to make IE run in version 11 emulation mode.
I do have a couple of workarounds: If the user runs IE first in admin mode, signs on, leaves it up while running my application, we don't get the problem. Second, I can start up the default browser - Chrome, IE, whatever - and send them to the URL for OAuth, then it avoids the error message.
The problem with this solution is that without being able to hook into TWebBrowser events, I don't have any way to automatically retrieve the OAuth key - it is necessary for the user to cut/paste it into my application. I'd like to avoid these clunky solutions.
I should also mention, this problem occurs only for certain Gmail accounts. I have no idea what the difference is between accounts that work and don't work. Any ideas on that?
So, is there any way to configure IE or TWebBrowser so this security issue is bypassed? Or, if I was to update to a modern version of C++Builder and use TWebBrowser (or something else?), would this problem be avoided? Any other ideas to fix this problem?
The latest C++Builder supports Google's Chromium engine, it's probably safe to say it'll be compatible with Google's security upgrades.
Powerful Chromium Based WebView Component To Host Web Content In Your Delphi/C++ Builder FireMonkey Apps
Related
We are migrating from deprecated Google Sign-in (basically gapi.auth and gapi.auth2 methods) into the new Google identity services (google.accounts.oauth2). More info here
We are using the authorization solely for Google picker. The problem is, beforehand (it seems) the library didn't return access_token in their gapi.auth.authorize, which was an indication that something wrong is going on and we've displayed "3rd party cookies blocked" message.
After the migration, the Google identity does not need any cookies, whatsoever, Google picker is somewhat unaware and stops working with 3rd party cookies blocked.
After the picker is successfully loaded, he prompts the user to SignIn (even though it just received a working token via setOAuthToken). After clicking the SignIn twice in the iframe, there is some malfunction error. Nothing is ever opened. NO callbacks are aware of this, no errors can be caught.
This behavior can be directly controled by the 3rd party cookie block. If the cookies are allowed. The exact same flow (and code) opens google drive picker (via build and setVisible) and everything works as expected.
The question is.
How to catch this 3rd party cookie error? Or any errors in the iframe whatsoever.
Why the picker requires 3rd party cookies?
Should I do something on the picker side for the migration as well?
Drive Picker and Drive API Third-party cookies
This has been reported as an issue from the community, I would highly suggest to also provide the feedback and insight regarding your concerns and future alternatives:
https://issuetracker.google.com/issues/188699186
Replying to your questions:
How to catch this 3rd party cookie error? Or any errors in the iframe whatsoever?
As suggested over the Issue tracker, it is not possible to catch information about the matter.
Why the picker requires 3rd party cookies?
It would be a great idea to request a better documentation on why over the issue tracker, as it was also suggested on a previous old post:
https://issuetracker.google.com/164130212
I notice that other types of Drive API process that can be troubleshooted generally recommend enabling or as an alternative to add an exception for accounts.google.com.
Should I do something on the picker side for the migration as well?
It seems you have followed the process of migration correctly, this is only a limitation from Drive Picker itself or the Drive API needing access to those cookies to run properly, might be a good test the exception suggested in the previous answer.
References:
https://developers.google.com/drive/api/troubleshoot-authentication-authorization
https://developers.google.com/identity/sign-in/web/troubleshooting#third-party_cookies_and_data_blocked
I am trying to access some services that require a google login. I thought it would be a really neat idea to automate it and have been trying to do so. Whenever I use my script to try and log in, however, I get this message:
This browser or app may not be secure. Learn more
Try using a different browser. If you’re already using a supported browser, you can refresh your screen and try again to sign in.
How do you go about getting around this? I tried researching it but came up with blanks. Is it possible to be logged in prior to running your script?
Logging in to Google is still possible (by exploiting a bypass).
By default, Google detects and effectively blocks all logins from Selenium webdriver.
The following link comes from the Google OAuth Playground, ensuring the practicality of the link. It most likely won't expire any time soon.
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&prompt=consent&response_type=code&client_id=407408718192.apps.googleusercontent.com&scope=email&access_type=offline&flowName=GeneralOAuthFlow
You can use that link (ie. driver.get()) to log into your Google account.
This bypasses the automation checks allows you to log into Google using Selenium. At least for now.
UPDATE: As of January 2021, this no longer works.
So I'm trying to register a new client on the instagram API. I have a business account and have done the proper steps prior to this. Everytime I fill out the "Register New Client ID" form and submit it, I get an error "The captcha solution was not correct. Please try again." But no there is no captcha for me to fill out!! Looking at the console errors it says the CSP page setting's are blocking this source https://www.google.com/recaptcha/api.js. I'm gonna take a wild guess and say that has the captcha I need that's not appearing..lol.
Anyway, I've disabled all my content blocking settings and JS is enabled on firefox (oh I'm using firefox developer edition btw) and no change. I've also tried this in chrome and safari, no change. I don't have this issue with other sites that use captchas.
Anyone have any idea what's going on?
'preciate it!
Had the same issue here on Google Chrome. Used IE11 (version 11.345.17134.0 to be exact), and captcha displayed instantly. I've successfully registered a new client
I suggest to wait until Instagram team realizes to upgrade their whatever scripts & parameters.
I found myself in the same scenario:
I'm logged on Instagram
I land to instagram.com/developer/clients/register/ over Google Chrome 70.0.3538.102 (no extensions)
No captcha. And I get the following from the console:
ps: I tried figuring out how to submit this specific report, but after several searches I find myself loosing too much time... to make them aware.
I have created a custom App URL for my iOS app. The URL format is similar to this:
myappname://texttobeparsed
This works fine when I paste the URL in safari, My App opens and correctly handles the URL. The problem is that other apps such as iMessage or Notes do not recognize this as a URL.
Why isn't this URL scheme being recognized as a URL? Could it have to do with how I set it up in my info.plist file or something else?
Or, does the URL need to be in a different format to be recognized?
I know it's possible to have the system recognize it as a URL in apps other than web-browsers because I've seen it before with other apps (ex. iTunes: itms://itunes.com/apps/appname or Twitter: twitter:// or Facebook: fb://).
There's nothing you can do about this. If the link isn't explicit (e.g. in an HTML email), these apps can just recognize a built-in set of standard URL schemes. itms:// is one of Apple's own schemes (for the iTunes Store), so it makes sense that it is supported in addition to the standard mailto://, http://, tel://... schemes.
Edit: I would guess that the information that is used to determine what constitutes a valid URL in text views etc. is cached somehow. Contrary to what I initially guessed, it seems that app-specific URLs do work in Notes, etc. I've tested this with tweetbot:// for example (which I have installed) and twitter:// (which I don't have installed) to verify that it doesn't just check for a pattern like *://, but actually uses information about the installed apps.
I'd suggest that you try to restart your device. If it's an issue with some cache, that might help and I don't think there's much else you could do if your URL scheme already works in Safari.
Update: I've installed the official Twitter app to test this, the twitter:// scheme wasn't immediately recognized in Notes, but after killing and restarting the Notes app, it worked.
Update 2: I've done a minimal test app with myappname:// as a custom URL scheme. Again, like with the Twitter app, it worked after restarting the Notes app, so it doesn't seem related to the popularity of the app or whether it's been submitted or not.
I can't answer as to why it's not working (beyond guessing that the link interpreter is hard-coded to only recognize certain URL schemes), but I can say that the typical way around this is to link to a web page, and have the web page redirect to your custom scheme.
It's slightly less elegant, because the user will see Safari open up briefly before being forwarded to your app, but it's also more robust because the web page can provide a link to the app store to install the app if it is not installed on the user's phone.
We have a mobile web based app at my company. Due to the nature of the application we do not want the browser on the users phone to prompt the user to save the passwords on the form a.k.a the autocomplete feature.
We managed to do that for IE and Firefox by setting the autocomplete tag to "off" but that doesnt seem to work for Opera mini (and i am guessing opera in general). I know user's can set it to off in their settings but for security reason we rather have it disabled?
Is there a workaround for this through code? the app is Java app using faces components based on an Jboss/Apache architecture.
In general, Opera lets the user configure whether it should respect autocomplete=off. On principle, users should be able to configure the password storage feature, and web sites should not be able to affect the configuration at a whim.
However, I can certainly see that for specific scenarios, like "send one-time passwords by SMS to the device Opera remembered the regular password on", this sucks. If you have stored password for a high-value site + use SMS one-time passwords as an "out of band" authentication, a lost phone becomes a major risk. The root of this problem is the assumption that an SMS constitutes "three-factor" authentication - if the stored login and the SMS is on the same device it's no longer "three-factor"..
It is tricky to try to leave users in control, while yielding to the web site when it's a really good idea to do so. Sadly, I think this is an unsolved question for now.
If you have a good use case for disabling password storage and are working on an important site, perhaps Opera Mini server admins could be persuaded to disable password manager on a site-specific basis? I don't know, but if you report it as a bug to Opera it would at least give the internal discussions some more momentum. Feel free to contact me with a reference to the bug report because I'm in a position where I could keep an eye on it ;-)