Google plus API is shutdown. What to do in ionic 3 app? - ionic-framework

I have an ionic v3 app and I have google plus login in it. I recently got a mail from google stating "Google+ API Shutdown"(refer here for more details). Google team has also said:
If you see API calls to people.get, these can be the result of using
the Google+ Sign-In feature in your application, which is now fully
deprecated and is being shut down. Developers should migrate from
the Google+ Sign-In feature to the more comprehensive Google Sign-in
authentication system.
You may see OAuth requests for plus.me, even
if your project is not requesting this scope directly. You only need
to remove such requests if your project is directly requesting this
scope.
I currently use'#ionic-native/google-plus' plugin.
Can someone let me know what should I do with the google plus API in case of an ionic v3 project ?

I've been told (secondhand) that although the plugin is named google-plus, it no longer uses the Google Plus APIs.

Related

Google login with flutter aad_oauth does not work because of webview

I am doing an azure active directory login with this plugin https://pub.dev/packages/aad_oauth.
However the plugin uses the webview plugin and the following error occurs because of that.
“You can’t sign in from this screen because this app doesn’t comply with Google’s secure browser policy”
Error 403 dissallowed_useragent
How do I get around this problem?
Google allows sign-in with Google Account only in normal browsers, it restricts it in web-views due to security reasons and recommends Google SDKs for iOS and Android for this purpose.
A similar behaviour exists for Facebook login.
In general, these services recognize the default WebView user agent, so to make it work, you could just set a custom user agent value.
You can use my flutter_inappwebview plugin to implement this logic.
I have created a project example that implements it and it's available at https://github.com/pichillilorenzo/flutter_inappwebview_examples/tree/main/third_party_oauth_user_sign_in

How to implement proper External Authentication in Cordova, Ionic w/ ASP .NET WebApi - Google/Facebook

I have a mobile application built upon Ionic Framework which uses many Cordova packages. We are upgrading the app from Ionic3 to Ionic5. In the Ionic3 application our .NET API was responsible to managing user logins. Going forward, in the Ionic5 app we will NOT be managing user credentials - we will be using 3rd party Identity Providers such as Google, Facebook, and Twitter.
We have implemented the Cordova packages to handle external authentication with Facebook and Google and it works fine. How do we tie the token that is received from Google/Facebook to our .NET API? When we try to use the token provided from Google/Facebook we - of course - get a 401 because our .NET API doesn't know about that token as it was issued from an external source.
I am aware of the process of how to enable the schema described here (External Authentication Services w/ASP.NET Web Api) but in this case the user agent browses to the Web Application in the browser. This is not true in my case as the user agent will be using a mobile application not a web site.
But I hope the principal is the same. But I'm missing something here.
The user will open the mobile app, authenticate with Google/Facebook and be issued a token. Now, what needs to happen to get that token to be recognized by my ASP.NET Web Api?
For example. When I registered my mobile app with Google Developer's Console I selected that the type of app is an Android application and was issued a Client ID for Android now how can I use this token in my ASP .NET Web API? There MUST be some way to tie the two together or some article out there.
Thanks in advance for your assistance!
Also, I looked at this post and see its 11 years old. Is there something here that I should be doing? Please help point me in the right direction. how-can-i-verify-a-google-authentication-api-access-token
It is about data ultimately, and identifying users in a consistent manner, then tracking their history with your app / business.
SOCIAL LOGIN PACKAGES
These are often cheap and nasty solutions that add complexity to your apps as you are finding.- especially when you need to look things up by user.
OPTION 1 - COMPLEX APPS
Your API could look at the token issuer (ISS claim in the token) and download token signing keys from either Facebook or Google - if JWKS endpoints exist. Then create a user from the access token's sub claim if required.
OPTION 2 - SIMPLER APPS
Deal with only a single type of token in your UIs and APIs, which will work like this. It moves the complexity to your Authorization Server (AS):
You have an Authorization Server (use Google maybe) to deal with token issuing and other central OAuth concerns
You have multiple Identity Providers (eg Facebook + Google) to support different login methods for users
During login Facebook posts a token to the AS
Then the AS issues its own token to your UI
The AS may be able to use Account Linking to provide a consistent user id regardless of login method
There is a learning curve in getting this working, but once done it can easily be scaled to many apps with zero code changes.
The proper answer is Auth0... see the below sequence diagram!

Link Analytics API to my Google Developers account

When I sign in to Google Developers console and go to the Enabled APIs tab, I see "No enabled APIs". I used to see the Analytics API here and now it's no longer there. That's because the project associated with it is gone.
I believe this happened when I switched my old Google account to the new Google Apps for Work account. It asked me to choose between the two because they had the same email address and I chose to keep the new one.
Unfortunately the old one had all the Developers APIs associated with it. :(
The Analytics API is still working, it's just no longer associated to my account. Is it possible to link it back to my account?
Thanks for your help,
Philip
PS. I can provide my Google email account and the Google Analytics API client id on request if needed.

Creating a non-web-view-based sign-in screen for Microsoft SkyDrive

I am trying to implement a sign in view like the one displayed below to allow users to sign into their Microsoft Live account and then allow the app to pull down their SkyDrive data.
I have been reading the API documentation at msdn and it seems that the documentation is centered on you using a standard web UI login form which I would like to avoid (pictured below).
So I am looking for documentation or an example of implementing a custom login form to login to windows live to get SkyDrive data. Any information would be extremely helpful as I am pretty stuck.
Note: There is also an issue open on github regarding the this same topic.
After doing some digging I discovered that microsoft will only allow you to log in using OAuth 2.0 through their interface (pictured above). What I originally wanted goes completely against the design of their SDK and isn't/wont be supported.
According to an issue posted on github, there may eventually be a way to allow authentication through the Skydrive iOS app. As of now however, there is only one way to authenticate, through their SDK or API.
This is also stated in the documentation:
Your app must initiate the sign-in process by contacting the Live Connect authorization web service.
Resources:
Documentation
Github Issue
LiveSDK-iOS

convert existing web application to Facebook Apps / Google Apps

Is there a way to take a existing web application and make it available as a Facebook application or in Google Marketplace without doing recoding. How much effort would that require (10% or 90% of original effort).
What would be the pre-requisites around that within application.
If your application don't use any sort of authentication, you can just link it on Facebook's dev dashboard (as iframe) and it'll work. My guess is that Facebook won't allow any other kind of authentication besides their own, so if your app uses authentication, then you're going to have to implement Facebook's authentication.
With Google Marketplace you'll need a manifest for your app and also a listing manifest. And the authentication thing also applies, but with Google's.