I'm having a lot of trouble testing my google action's account linking. It uses the authorization oauth2 flow for account linking. I do not have transactions enabled but instead have required sign-in on the welcome intent and both of my other (custom) intents.
Immediately after implementing account linking, I tested the flow via the simulator and it worked perfectly. I then wanted to link my google account to a different account on my server, which means I needed to unlink and then link again. This is where things get fuuuuunky.
It looks like the docs are a bit outdated, but I eventually found a way to unlink, at least partially. The note in the blue box at the bottom of this page notes that you can unlink by disabling testing. The UI looks different from the screenshot, but I disabled testing within the Action Simulator UI by toggling 'Testing on Device'. I then re-enabled it and indeed my requests were no longer getting access tokens!
However, at this point, the linking flow was no longer being invoked when I ran commands via the simulator. I waited for a few hours and tried again - no dice. My dialogflow webhook simply isn't getting an access_token in the request body (property no longer exists), which is good, but I'm never prompted to re-link the account.
I tried the same using the Google Assistant app on a phone registered to my google account (same Google account being used in the simulator). Again, it worked the first time but after I toggled testing on my device, it started to fail permanently. So it seems device-specific? I did try an incognito chrome session as well as deleting cookies, neither of which worked.
Any ideas how I can properly unlink and then re-link my account during testing of a google action?
Thanks!
Related
I was using another github account (abc#gmail.com), but now I wanted to use xyz#gmail.com account, and signout signin still keeps the repositories of abc#gmail.com Yes I am using Github Desktop.
It looks like the desktop app uses your default browsers cache to get the sign in information. I would recommend clearing your cache and cookies then closing all browser instances once that's done. (Make sure time range says all time if in chrome or edge) Make sure to be already signed out of the desktop app before doing this to avoid any cross caching.
I have created a conversational action in Actions Builder that uses account linking via OAuth (not Google sign in). Functionally, everything is working well.
The only issue I noticed is that when I try to link accounts using anything except a phone in the simulator, I get a response telling me to link accounts using the Google Home app. Since my action is a conversational action and not a smart home action, my action will never be found in the Google Home app.
I have confirmed that this kind of account linking is supported with conversational actions (via docs as well as Actions on Google support). What support could not answer for me is what I can do about this, they directed me here for help.
So my question is, how is account linking handled for conversational actions on non-phone devices (e.g. smart speaker)? Does it simply not run at all, or do I have to do something to remove these Google Home prompts?
Thanks
If the Action is running on a device type that does not support a web browser then the authentication step is not going to work. If you have not signed in before, the operation will fail. Though if you have signed in already, any device will be able to retrieve your access token.
The way to do this would be to handle cases for a non-authenticated device that cannot be authenticated. This may mean providing some part of your Action that can run in these conditions. Alternately, you'll need to inform people that they'll first need to use their phone to perform account linking.
I've developed a Google Smart Home action and it is live on the Google Assistant and Google Home app.
Account Linking, Device Creation, and Device Control seem to all be working fine.
The one complaint we receive is that sometimes, after around a month, the devices seem to lose connection to the Google Assistant app.
When attempting to send a command, we get the most message "Sorry it looks like the is unavailable right now." The devices still show up under Home control and the action still appears under "Linked". The command event never reaches our Lambda function.
Does this problem description sound like a red flag towards any aspect of the integration?
I'm wondering if it is maybe a token that isn't being refreshed correctly? So that after the month, Google kicks us out? I only think this because of the consistent time frame the error occurs at. No idea though haha. I don't remember seeing anything in the docs or the sample action (https://github.com/actions-on-google/smart-home-nodejs) that mentioned preventing expirations from occurring.
Thank you for your help in advance!
You can review the error logs for your project, which will indicate if errors are occurring due to account linking or something else related to your intent fulfillment.
I'm wondering if it is maybe a token that isn't being refreshed correctly?
This is a reasonable place to start, and your error logs will indicate if there are account linking errors. For example, your OAuth server may be expiring the refresh token before a new one is delivered to Google Assistant. You can find more details on implementing OAuth token exchange in the documentation, including a note about rotating refresh tokens.
Note that Google Assistant generally only refreshes the access token when an intent needs to be sent (i.e. not immediately once the token expires). Sometimes this can also affect the refresh behavior of your OAuth server.
I created a DialogFlow app that works perfectly in my developer account.
But I need to test it as another user, so in my Google Action simulator, I added another test account as a OWNER to the project.
I verified this user has OWNER status in both the DialogFlow and Google Action UI.
They are able to edit both projects with full access.
However, when the test account tries to use the simulator it says:
Sorry, this action is not available for your app. Sorry, this action
is not available for your app. In the simulator, you are only able to
invoke actions that you have added to your app. For more information
on how to invoke your app, click here
https://developers.google.com/actions/discovery/explicit
This makes no sense to me:
I verified the test user has OWNER/ADMIN status on both DialogFlow and Google Actions for the project.
In DialogFlow, I verified the Google Assist is pointing to Default Welcome Intent as the default intent.
In Google Actions, I verified that the Default Welcome Intent is visible on the BUILD > ACTIONS UI.
As others suggested, I tried renaming the app several times with no luck.
I tried publishing an Alpha version, with still no luck.
My gut tells me it is some sort of permission/visibility problem, but I am completely stuck. Any ideas would be of great help.
EDIT:
THIS ISSUE HAS BEEN SOLVED. SEE COMMENT BELOW.
"I revisited my activity controls and noticed my "Web and App Activity" had a special clause due to organization permissions. I completely missed it due to the confusing UI. Posted a picture in the main thread. Thanks for reminding me to double check that area."
After you asked your company admin to enable this feature, it should be same as the image in below.
This error message is quite misleading. I have encountered this error a couple of times, and generally the problem was with one of the privacy settings in my Google account.
In this case you should go to https://myaccount.google.com/activitycontrols, confirm that you are logged in using your test account, and make sure the following are enabled:
Web & App Activity
Device Information
Voice & Audio Activity
I've written an authorization flow for my action, to do account linking with the "Implicit flow". I have been testing it using the web simulator. When I try to run the action in the web simulator it tells me to link my account, and provides a URL:
"https://assistant.google.com/services/auth/handoffs/auth/start?provider=hello_dev&return_url=https://www.google.com/"
I run that URL and this is what happens:
My Java servlet receives the auth request from google. It contains what is documented, a GOOGLE_CLIENT_ID, a REDIRECT_URI, a STATE and "response_type=token"
I create an access-token from the Google ID that is logged in by using UserServiceFactory.getUserService().getCurrentUser().getUserId()
I craft a URL to the redirect-uri that contains my ACCESS_TOKEN, token_type=bearer, and state= the state string I originally received
I create a web page for the user that contains that link so they can click it and it executes the link and my account is linked.
That works great and the response is a blank page with a URL that says: "https://www.google.com/?result_code=SUCCESS&result_message=Accounts+now+linked."
However, I wanted a flow that allowed the user to ensure they are logged in, and logged into the Google Account they wanted to link
So, I also present a link that logs them out if they'd like. The link is created by using userService.createLogoutURL(thisUrl)
If they do that, I then present them a link to log in, created using userService.createLoginURL(thisUrl)
Once they have logged in, with a different Google ID, they are back on the original page which allows them to log out again or click the "link account" link.
The situation is, that if they click the "link account" link now, the EXACT same link that would have worked successfully before they logged out (except a different ACCESS_TOKEN value) and logged back in with a different account, the response is a blank page with a URL that says: "https://www.google.com/?result_code=FAILURE&result_message=Account+linking+failed"
Two things of note:
If they log out and log back in with the same account, then the "link account" URL works fine
If they are not logged in at all when beginning the process, and then log in and then use the "link account" link it works fine
So, the only time it fails is when they are logged in, log out, log in with a different account, and click to link accounts. That's when it fails.
The account doesn't matter, multiple different accounts work, as long as the browser is logged into the first account and doesn't change during the flow.
I honestly cannot imagine how this is happening.
This gets even worse if I do it in the Google Home app, as it then returns some "malformed request error" page and basically stops working, PERMANENTLY. Stopping/Starting the action didn't help. Stopping/Starting the Web service didn't help. Rebooting the Android device didn't help. Link Account from the Google Home app was permanently broken. The only way I was able to get it working again was to use the Account Link URL (gotten from the web simulator) in the Chrome Browser on my Android device, which seemed to "reset" everything.
At this time, we require that the Google user who initiates the account linking process, both via the simulator and Google Home application, be the same Google user that logs in via a Google Sign-in option, if it is offered as part of your auth flow. This is a hard requirement.
For this reason, we'd suggest not offering a Google logout option as part of your account linking process.