I am developing an Eclipse plugin where user needs to login to their Facebook account in an SWT brower. I am using the way, described here to try to get the access token from the url. It had worked well until today. The problem is that redirected uri is no longer followed by "access_token=..." any more. Then I mannually tried to get the access token from url in real browsers. It works on Chrome and FireFox, not on IE. In my progrm, the SWT browser is defined as follows:
Browser browser = new Browser(container, SWT.NONE);
I guess it must've used IE in the background and IE for some reason hides the access_token from the url. Any idea for unhiding the access token?
Any input is greatly appreciated!
The following answer refers only to the SWT part of your issue.
org.eclipse.swt.browser.Browser is using a native renderer for each platform it supports.
For Windows the default happens to be IE.
Depending on your use case (i.e. OS, Eclipse versions you need to support), you can force the widget to use a different native renderer.
Related
After upgrading Microsoft.Identity.Client within Xamarin.Forms from 1.x to 4.x, most things work much the same. However, login to iOS results in a popup that says:
"My App" Wants to Use "b2clogin.com" to Sign In
This allows the app and website to share information about you.
It's OK if user hits continue, but it's hardly seamless.
Supposedly it's associated with iOS 12, but that doesn't seem to be the trigger for me. There's a Microsoft article that says this is actually normal, stating:
On iOS, though, the user might have to give consent for the browser to call back the application, which can be annoying.
I found that it's possible to set .WithUseEmbeddedWebView(true) and this hides the URL as well as removing the popup, and this works with Facebook sign in, but Google sign in is a hard no.
There's the potential path of Universal Links instead of URL Schemes and Associated Domains.
Investigating that path, it appears that I simply need to set the URL https://myapp.b2clogin.com/.well-known/apple-app-site-association with the following JSON:
{
"webcredentials": {
"apps": [
"MYTEAMID.com.mycompany.myapp"
]
}
}
Unfortunately, I don't have control of that URL.
Any other ideas?
The short answer is -- it can't be done today as this alert pop-up is built into the iOS framework. Any authentication provider, library, etc. will trigger this alert if they use the ASWebAuthentication API in iOS
You can choose to use different embedded-browser pop-up APIs which do not cause this alert, however they will have sandboxed cookies and the user may not experience SSO. There is an MSAL docs page which discusses this in a bit more detail:
https://learn.microsoft.com/en-us/azure/active-directory/develop/customize-webviews
The best user experience:
I use ROPC for signIn only (native username/password fields or could be with biometry).
So I don't have any popup at simple Sign In.
For the rest I use commons Flows (Reset password, Google provider etc..)
that open the WebView with unfortunately the warning popup.
When a user clicks a link to my site inside their LinkedIn app it doesn't take them to Safari or Chrome, it keeps them in an internal LinkedIn browser.
If the user then tries to create an account via Google OAuth they get the following error (see image).
Is there a way to prevent LinkedIn from opening a link in their proprietary browser, and take them to Safari or Chrome automatically? Or another workaround for this issue?
Neither you can restrict LinkedIn to open your site in other browser nor to stop google to throw the error. To solve this problem, You have to write a script which will open your website in the default browser of the user's device. Whenever user hit your website then check the web browser if it's chrome, safari or any other web browser then continue the request else force the user to open website in user's default browser using the script. That's it.
Hope this suggestion will help you.
I'm new to chrome extensions but I can't seem to understand what value the identity.launchWebAuthFlow adds over windows.create. I'm trying to use Oauth from an external provider. There doesn't appear to be any automatic persistence of an identity token as part of that flow. Also other browsers do not (yet?) support the identity.launchWebAuthFlow function. Both of which point to NOT using it vs a normal popup.
What am I overlooking?
chrome.identity.launchWebAuthFlow launches your authentication page in a window until it comes back to https://<app-id>.chromiumapp.org/*, and then the callback fires.
chrome.windows.create launches any URL and then fires the callback with the window object.
There's one significant advantage to chrome.identity.launchWebAuthFlow, from the docs:
Since some auth flows may immediately redirect to a result URL, launchWebAuthFlow hides its web view until the first navigation either redirects to the final URL, or finishes loading a page meant to be displayed.
This means that you can seamlessly sign in (if your auth supports it)
This has been driving me nuts all day:
I have an iOS app with a custom URL scheme defined, and am trying to share a link on FB which points to a page that has this scheme in its applink meta tags, so that tapping it should fire up my app.
Every little piece of it is working just fine. I can enter my URL scheme in safari on the phone and the browser launches my app. I have tested my webpage with the FB debug tool and there are no errors or warnings - it correctly identifies all the meta tags.
If I share the link using FB on the phone or on my laptop, all works fine.
HOWEVER, if I share the exact same link using FBSDKShareDialog, it does not work. It just opens the web page with the meta tags as if it was any regular web page.
Anyone has any idea why these two ways of sharing would be different? They look exactly the same otherwise.
If anyone else runs into this problem, here's the reply from FB:
When you share with mode automatic, the app does a fast app switch over to the FB app to show the native share dialog
The post is cached locally on the device, and it does not know about app links (since only Facebook server side knows about it)
When the user opens the FB, the user sees their cached story (with no app links behavior),
This doesn't manifest with the Web mode since the Facebook app needs
to pull from the server to get the post, in which case it has all the
app links info.
This is unlikely something that we'll fix. However, after a while, the
cache will expire, and Facebook app will re-pull the posts from the
servers, in which case the app link data will be available.
In order to test this, you can share the post on one device, and then
try clicking on the post from another device. The app links should
work at that point.
Which is kind of a lame response IMO - they parse the target page to build the preview, how hard would it be to remember the applink and use it?
There could be two possible issues:
Either the one told by #NJ, i.e. you are just trying to open the link in Facebook app, using the same device from which you posted the link.'
Solution - either open link in other device or cose and re-open your facebook app and do multiple refresh
Or You have some error in your meta tags. There is one important thing though, that Facebook never mentions, i.e. they cache the URL you provide.
So any one used the web link with meta tags the first time in Facebook, Whole meta tags will be cached, and you updated meta tags won't be parsed by facebook.
Solution
To get over with the issue, use below link
Facebook debug tool
Input your meta data included web page URL and
-click on show existing scrape information to find any error
Click on Fetch new scrape information for refreshing your URL on facebook. it will clear the cache for that URL in facebook server.
A previously working desktop application (until Friday of last week) was using the methods described here: http://instagram.com/developer/authentication/ to log a user in to Instagram. The application is a desktop application and it uses the IE browser component http://i.imgur.com/bCB5ZZh.png embedded in the program to show the user the Instagram login page and grab the auth token from the query string. But something has changed recently on the Instagram login page.
The easiest way to see what is happening is to watch this screen capture:
https://cloudup.com/cKQFpVcTv8E
Basically, there seems to be an error in History.js when opened in a HTML 4 browser like the IE browser component built into windows: http://i.imgur.com/HHJYidI.png
And if I load the full authorization URL ie: https://instagram.com/accounts/login/?next=%2Foauth%2Fauthorize%2F%3Fclient_id%3Dxxxxxxxxxxx%26redirect_uri%3Dhttp%3A%2F%2Fwww.xxxxx.com%26response_type%3Dtoken%26scope%3Dlikes%2Bcomments
... the browser component keeps redirecting and loading adding a "#" to the end of the query string.
I've found a few leads on SO:
History.js for HTML5 - Hack Needed to Not Break IE7
AND
history.js and header redirection
These seem to indicate that History.js needs to be modified to work with older browsers, but of course that would be something Instagram needs to do.
Again, this has been working for well over a year until late last week.