The Amazon skill was set up with login with Amazon for oAuth, after successful login into Amazon, the Alexa app throws up and error saying "an error occurred while attempting to link Alexa with . Please try again later" Are there any other configurations that I might be missing? Alexa was launched in India very recently. Anything specific that needs to be done for this region?
Link to the skill configuration
Link to LWA configuration
The issue was in the skill configuration. In the current release of the smart home skills API, Amazon provides developers with an inbound endpoint on Alexa. This allows developers to send asynchronous messages to the Alexa service.
This requires region-specific lambda functions and an authorization framework set-up by the developer.
documentation on sending events to the Event Gateway is here.
As far as I could find out, this is not yet enabled in India- only EU and the US
In the screenshot attached to the question, you can barely see this enabled under the "Permissions" section.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
We are integrating the Gmail API with Integromat and, in order to avoid re-authorizing Integromat’s access every 7 days, we need to submit for Google verification.
Now the problem is that the Google verification wants to verify the ownership of each domain. I’m afraid this includes the integromat.com domain (since integromat.com is the authorized domain). That’s a problem since we don’t own the integromat.com domain and we therefore cannot verify domain ownership. Is there a contingency plan for this?
Besides, Google wants a YouTube video showcasing how the permission is being used, which is quite a silly requirement since our Integromat account is only used by us (obviously).
I wonder whether Make/Integromat has some official recommendation/help for this? I couldn’t find any so far.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option.
You have two issues here. The refresh token expiring, and your desire to submit your application for verification.
These are separate issues that are unrelated.
expiring token
Refresh token expiring after seven days is due to the fact that your application is currently in testing phase not that it has not been verified.
refresh token expiration
A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
On the Ouath2 screen set the project to production and your tokens will stop expiring.
verification
Domain name:
If you are using a domain name either for redirect uri or hosting of your privacy policy. You must verify that you own this domain though though google search console. There is no way around this.
If you don't own integromat.com your not going to be able to use that. Host it on your own domain.
Gmail scopes are one of hardest scopes to be able to get an application verified for.
YouTube Video:
You will need to create a YouTube video and host it public so that the security team can verify what your application is doing and how it its intended to work. It is not a silly requirement. It is there to protect your users data.
Remember the third party security assessment for gmail scopes is going to cost you between 15k-75k dollars a year.
internal
As stated in exceptions-to-verification-requirements
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
Your last line says.
Note that we are not using Google Workspaces so we can’t use Google’s "internal usage" option
You don't need to be verified. So you dont need to worry about the domain, or the youtube video.
We have a mobile app and our users got a
"sign in with google temporarily disabled for this app"
When they tried to login their YouTube account with iOS (There's no problem with Android devices).
We submitted a verification request long time ago, and we got from YouTube an email (May 26th 2020),(May 26th 2020):
"Hi Adam,
Thanks for working with us on the YouTube API Services compliance review. We have completed your review and do not require any further actions from you at this time.
We may reach out again to re-review your API Client for compliance with YouTube API Services Terms and Policies.
We appreciate your time working with us on this and please continue to comply with the YouTube API Services Terms and Policies."
Since then, nothing had changed and our app hasn't been verified yet, and our users can't connect with their youtube accounts.
What can we do? We are just waiting and we don't even know how to contact YouTube and ask about our specific case/project.
Thanks you,
Adam.
sign in with google temporarily disabled for this app
Means that your application has not been verified by google. You need to go through the verification process.
You can use a project for development without verification. However there are some limitations (more information here). Basically, you have now reached the limit of 100 users accessing the application.
If you still havent heard anything from google after they say they have verified your application I think the only thing you can do is to submit it again and double check that you are using a client that was created under the project that you requested verification for there's really nothing else you can do.
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
❗ But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
I am using RPXnow.com authentication solution for a rails app and am now at the point of wanting to develop Facebook integration features using Facebook Connect and the client api. What I am unclear on from RPXnow docs is the level of integration their solution provides. When a user connects via rpx using their FB creds, are they now using Facebook Connect? Can I make calls to the client api from my app? Do I need to use the RPX api to access the FB client APIs?
Anyone with experience using both who can shed light here, much appreciated.
dnewman,
Great question. Facebook Connect is simply a javascript layer built on top of the Facebook Platform APIs. RPX uses the platform APIs to authenticate the user, and after they have signed in, you may safely use the native Facebook Connect javascript to implement FB specific features on your site like posting activity back to the News Feed. You just need to set your connect URL on the facebook developer site and drop in the Facebook Connect javascript and then start implementing. After authenticating via RPX, the user will already have approved and "connected" to your website, and you'll have access to the breadth of Connect directly.
Also, if you have an RPX Plus/Pro account you can make simple RPX API calls to set a user's status and post activity on Facebook (and Twitter/MySpace).
Brian Ellin
RPX Product Manager
Once you've hooked up RPXNow (JanRain) single sign-on, you can follow the Facebook documentation. The Server-side Personalization example is in PHP but the idea is the same in any language.
// Fetch the user's friends
$friends = json_decode(file_get_contents(
'https://graph.facebook.com/me/friends?access_token=' .
$cookie['oauth_access_token']), true);
$friend_ids = array_keys($friends);
The key point to note is that the $cookie['oauth_access_token'] referenced in this example needs to be the string returned by the RPXNow sign-on API response in the JSON field
['accessCredentials']['accessToken']
Hint: from your RPXNow dashboard, check out the Test Sign-In Widget page under Resources to see where that token is in the response.
Initially I thought this would be hampered by having your Base Domain set to rpxnow.com in your Facebook Application settings, but this is not the case. It works fine.