So this type of error is being reported on a lot of community boards over the course of the last year with no acceptable answer we could find. We have just started our journey integrating with Google Home and created a Home Automation Action and we are getting a similar error …
{
insertId: "10wvnj2fyb1thy"
logName: "projects/bitdog-home-f69bd/logs/actions.googleapis.com%2Factions"
Show matching entries
Hide matching entries
Add field to summary line
receiveTimestamp: "2018-12-06T13:28:13.939975519Z"
resource: {
labels: {
action_id: "SMART_HOME_SYNC"
project_id: "bitdog-home-f69bd"
version_id: ""
}
type: "assistant_action"
}
severity: "ERROR"
textPayload: "SYNC: Request ID 742344561631232315 failed with code: OPEN_AUTH_FAILURE"
timestamp: "2018-12-06T13:28:13.931998358Z"
}
This shows on Google Home app as "Couldn't update the setting, check your connection"
The OAuth service logs show a successful account linking and a successful refresh_token request. Google does not attempt a SYNC call to the Action handler from what we can tell.
We have other systems using the OAuth server and they are working well and we are little lost on how to proceed to debug this issue. We created a support ticket today but I don't feel confident that we will get meaningful help.
We have also tried using the Google Home app on Android and iOS. We have tried changing the default browser from Chrome to Firefox. Nothing has changed the outcome. We also made sure that our access_token was in JWT format to see if google was sensitive to token size or format and nothing worked. We even made sure that the Google Home app user matched the user logged into the browser.
Help!
I did get it working. It was already working with an Amazon Echo Skill but it seems that Google's implementation (OpenAuth) is a bit more strict. I changed my access_token from a proprietary encrypted token format to a legit signed JWT token. I also removed expires_in from the response and it started working, not sure if it was the access_token JWT token format or removal of expires_in. I'm happy I can move on. If I get a chance, I will test to see which change made it work and comment here again.
Thank you.
To anyone with this problem–
I had to take multiple steps to resolve this issue, which are not clearly outlined in any documentation.
As per Google support:
Please adjust your account linking implementation from implicit to auth code flow then perform test again.
On the documentation for OAuth account linking, it says there are two methods of authentication: implicit and auth code. Apparently, only the auth code flow works for smart home.
I am using the Actions on Google Node.js library. While poking through the documentation, I found that:
[The SYNC request fulfillment] should return a valid response or a Promise that resolves to valid response.
The problem is that I was doing a database operation (which took time), so I couldn't simply return a value when it was ready; I had to return a Promise insead, then fulfill that promise later.
Hopefully this is helpful to anyone stuck on this reoccurring issue! Basically, check your auth flow and make SYNC is returning a valid JS object on time.
I was facing the same issue from last 2 weeks and was wonder when saw it is a 3 steps problem.
Check your SYNC intent is properly parsed
Incorrect Response Structure (Verify here-Smart Home SYNC Data Validator)
Device Response time-out should be less than 5 sec.
You can check Link
My problem started when I connected by Sonoff Bridge.
So I got it working by removing my 'Sonoff Bridge' and connecting it to Google Home. (All mu light are now working). Added the Bridge again to Sonoff and using IFTTT to connect to my Bridge
Related
For a while now I've been using dropbopx-sdk-js in a Meteor application without any trouble.
My Meteor app simply uses Dropbox to fetch images to be used in product cards. These files are synced now and then and that's it. By synced what I mean is they are scanned, shared links created or obtained, and some info is then saved in Mongo (name, extension, path, public link)
End users do not remove nor add files, nor are the files related to an end user specific account.
To achieve this, I created (in the far past) an App in the Dropbox App Console, generated a permanent token, and used that token in my Meteor app to handle all the syncing.
Now I've tried to replicate that very same thing in a new similar project, but found that the permanent tokens have been recently deprecated and are no longer an option.
Now, checking Dropbox's Authentication Types it seems to me like "App Authentication"
"This type only uses the app's own app key and secret, and doesn't
identify a specific user or team".
is what I'm after. I can safely provide app key and secret in the server exclusively, as the client will never need those. The question is how do I achieve such kind of authentication? Or for that matter, how do I achieve an equivalent of the long-lived token for my app, ultimately meaning that end users don't actually need to know Dropbox is behind the scenes in any way (and they surely don't need dropbox accounts to use this app nor should be prompted with any Dropbox authentication page)
In the js-sdk examples repo, I only found this example using app key and secret. Yet afterwards it goes through the oauth process in the browser anyways. If I don't do the oauth part, I get an error
"error": {
"name": "DropboxResponseError",
"status": 409,
"headers": {},
"error": {
"error_summary": "path/unsupported_content_type/...",
"error": {
".tag": "path",
"path": {
".tag": "unsupported_content_type"
}
}
}
}
as a result of calling
dbx.filesListFolders({ path: '', recursive: true }):
If I replace the initialization of the dbx object with a generated token everything works out. However eventually the token expires and I'm back in square one.
Any ideas what may I be missing?
The short answer is:
You need to obtain a refresh-token. You can then use this token for as long as you want. But in order to get it is necessary to go through at least one oauth flow in the browser. Then capturing the generated refresh-token in the backend. Then store it and use it to initialize the API. So it's kind of "hacky" (IMO).
For example, you can use the mentioned example code, and log/store the obtained refresh token in this line (as per Greg's accepted answer in the forum). Then use that value as a constant to immediately call the setRefreshToken method (as done in that very same line) upon initialization.
The long answer is:
ClientId + Client secret are not enough to programmatically generate a refresh token.
Going through the oauth flow at least once is mandatory to obtain a refresh token
If you want to hide such flow from your clients, you'll need to do what the short answer says.
The intended flow of usage according to Dropbox is: each user access his own files. Having several users accessing a single folder is not officially supported.
The longer answer is:
Check out the conversation we had in the dropbox forum
I suggested to replace the "Generate Access Token" button in the console for a "Generate Refresh Token" button instead. At least it made sense to me according to what we discussed. Maybe if it gets some likes... ;).
We keep playing this cat and mouse game with Robinhood.com. I have a trading app which used to trade stocks with Robinhood, but they keep changing the unsupported unofficial API to make it difficult for traders to use. I know that many people are doing the same thing and I want to reach out to them to see if there is a new answer. The latest problem is when I try to get a Bearer token using the URL https://api.robinhood.com/oauth2/token/ the API returns the following JSON: {"detail":"This version of Robinhood is no longer supported. Please update your app or use Robinhood for Web to log in to your account."}. This started happening on 4/26/2019.
Has anyone found a work around for this, yet, or have they finally beaten us into submission?
A more complete solution (not need browser):
Use requests.session.
Obtain the login page by making a GET request to "https://robinhood.com/login".
At this point the session's cookies will contain 'device_id'.
Obtain this device_id and use it in making the oauth2 token request to "https://api.robinhood.com/oauth2/token/" also add in the data request "challenge_type" (either "sms" or "email").
This request will fail with a 400 error code. Robinhood will send an SMS message or Email with a temporary (5 minute) code.
Also at this point use the 400 response's body to get "id" from "challenge" inside of the JSON object.
Confirm the challenge by making a POST request to "https://api.robinhood.com/challenge/CHALLENGEID/respond/" where CHALLENGEID is the same id mentioned in the first failed /oauth2/token/ POST request.
Make the same POST request to "https://api.robinhood.com/oauth2/token/" and include in the header "X-ROBINHOOD-CHALLENGE-RESPONSE-ID" with the value CHALLENGEID.
You can reuse a device_id with user/pass after this even after logging out.
Be cautious with storing device_id as it is the result of user/pass login and successful SMS/email 2FA.
Just got it working. At the risk of them seeing this post and changing it more, here we go:
First, you're going to want to log into your RH account in a web browser
View Source on the page, and look for clientId - it should be a big hex number separated by dashes
Add that number to your POST requests to /oauth2/token under the field device_token
There's probably another way to retrieve the device token, and I'm not even sure it's unique, but that way should work.
Good to be back here after a very long time.
Not sure if anyone is still looking for answers to this, but I have a very simple solution.
At Robinhood's login screen, enter your username/email and your password, press F12 on your keyboard to bring up the console panel and switch to the "Network" tab then wait for the page to load completely. (During this time you will see a list of items being loaded rapidly depending on the connection speed.)
At this time you can keep clearing the list by clicking on the button highlighted in the below image.
Click on button highlighted repeatedly until the list is empty
Now, log into your Robinhood account. At this point your console should display a list similar to the one shown below.
Look for the name "token/", most likely it will be the second one you get all the information you need. And this information will be under the Headers then Request Payload
I was able to find this with past knowledge and experience of web scraping for fun. And also, I needed to know this as well, since I recently started doing trades via Robinhood.
Hope this help you curious ones out there.
For my Robinhood account I am using Google Authenticator for my 2FA. What I have so far is that I send the original call that I was sending before to https://api.robinhood.com/oauth2/token/. This is giving me a response of:
{"mfa_required":true,"mfa_type":"app"}
I then repeat my oauth token request, but this time providing the value from Google Authenticator (so my GUI has to prompt me to fill it in) with this payload in the request to https://api.robinhood.com/oauth2/token/:
{"grant_type":"password","scope":"internal","client_id":"c82SH0WZOsabOXGP2sxqcj34FxkvfnWRZBKlBjFS","expires_in":86400,"device_token":"***","username":"***","password":"****","mfa_code":"***"}
and then I am getting an access token in reply
the last couple of days I implemented the autodiscovery/auth flow for UCWA against Skype for Business Online and AzureAD. When I'm done and having the URL to the application directory (+ the OAuth2 Credentials) I save those into our internal system. So later on I want to create online meetings with this data. The URL to the applications directory looks like this: https:\/\/webpoolam42e10.infra.lync.com\/ucwa\/oauth\/v1\/applications\/101331226048\/onlineMeetings\/myOnlineMeetings
If I do this within the first minutes of retrieving the data it works just fine. But later on it seems, that the application directory is gone. I'm getting this response:
body":"{\"code\":\"NotFound\",\"
subcode\":\"ApplicationNotFound\",\"message\":\"An error occurred. Please retry. If the problem persists, contact your support team.\"}
Status Code is 404.
Later on I even tend to get 401 errors that mean unauthorized.
I suspect the application server going away and only being temporarily available. I got a refresh token and a valid access token, so this wont be a problem. I've got no clue what is going on there and wasnt able to find help in the docs. So maybe one of you got any advice - I'd be really thankful!
Side-Info:
I'm doing all this in PHP and I only have user-interaction at the initial authentication. I save the refresh token and all other things I need, so that my server-side application can use the authorization in long term.
Reporting here part of my reply to another question:
Keeping a UCWA App always online:
If you need to achieve that, you need to understand and implement correctly the concepts explained here me Dashboard, especially at Reporting activity section:
call reportMyActivity every 4 minutes max.
maintain an active P-GET with the Events Channel
handle possible timeouts on the Events Channel
handle possible DELETE events (on the Events Channel) the server can send for the application, for which you'll have to regenerate your app Application dashboard
reporting app's activity, and keeping a valid open P-GET with Events Channel are both very important!
I am using the Google Cloud Messaging services described at https://developers.google.com/instance-id/reference/server but I am getting a HTTP response status of 400 and this response text:
{"error":"InvalidTokenVersion"}
At the time I write this, that exact error code has zero results on Google! Has anyone else encountered it? I could understand "InvalidToken" but it is the "Version" bit which is confusing me.
I'd like to see a nice list of all the possible error codes for the https://iid.googleapis.com/iid/info/ and https://iid.googleapis.com/iid/v1/*/rel/topics/* services, if you know where that is?!
All the GCM pages say at present is...
HTTP status 400 (Bad request) - request parameters are missing or invalid. Check error messages for detailed information.
Background information:
I am using a registration token from an Android device which still shows a log of successful notifications in the GCM Diagnostics (part of Google Play Developer Console). So surely the token cannot be wrong?
If I try a token value of "bum" I get error "InvalidToken" instead.
However, trying to send a new notification with https://gcm-http.googleapis.com/gcm/send results in the "InvalidRegistration" error, so I guess something has gone screwy.
I'd like to claim that I've changed nothing recently, but something to do with SSL on the server might have expired I suppose.
The token you are providing is regId not instanceId.token. Follow the documentation:
https://developers.google.com/cloud-messaging/android/client.
see examples here.
https://github.com/googlesamples/google-services/tree/master/android/gcm/app/src/main/java/gcm/play/android/samples/com/gcmquickstart
What are the possible reasons that can cause token to become expired (besides having the user un-authorising the app)?
My problem is that I have an app with several thousands of users, all API communication works perfectly but for some users I am getting the invalid or expired token error, my initial though was that they are users who canceled the authentication to the app but I've contacted some of them and they haven't revoked the access.
Any ideas what other issues can cause that error?
Check the integrity of an access token at any time by calling the GET account/verify_credentials while using that access token.
Its mentioned and by research I came to know that:
Your access token will be invalid if a user explicitly rejects your
application from their settings or if a Twitter admin suspends your
application. If your application is suspended there will be a note on
your application page saying that it has been suspended.
Why is my twitter oauth access token invalid / expired ?
Check this post: invalid / expired access tokens.
There is one post in google groups that says:
You don't get a second chance, and this is by design. OAuth requests
have a unique signature; once a particular request is submitted, it
can't be submitted again.
If they enter the pin correctly, all is well, you get an access token.
If they enter the pin wrong, you get 401 Unauthorized - which is
expected.
But if they then try again to enter the pin, even the correct pin
shows as unauthorized.
Check this link for the above reference.
Some suggestions by twitter employee for the same problem:
I guess there are two things I would suggest at this point: 1.) Go to
your application settings and use the "Reset keys" tab to reset your
consumer key and secret, then update those values in the app and
verify that you still see the same behavior. 2.) Try passing
oauth_callback in your request_token call. Honestly I don't think this
will make a difference, but I want to try and be as rigorous as I can
here.
Also check this discussion saying:
You need to use the oauth_token and oauth_token_secret returned from
the oauth/access_token call instead of the one in your app's settings
in dev.twitter.com
I was getting same error then I changed (access_token) to (access_token_key) and it worked for me.
I hope it will help someone.
In addition to the comments everyone else has made, sometimes the twitter api will return a "invalid token" error when the token isn't the problem. I've noticed it the most when I've built a request string that doesn't parse correctly. For example, once I was getting that error when I was passing in screen_name's that had symbols that weren't URI-encodable. I also have gotten it when I passed in empty values like this (where the cursor is empty):
https://api.twitter.com/1/followers.json?cursor=&screen_name=whatevah
Could you give us the specifics of the calls that are returning this error?
Have you confirmed that the tokens worked at one time? In an OAuth system I worked on, there was an error in how tokens were securely stored and retrieved that caused a small percentage of them to become corrupted. If you can confirm that the tokens worked in the past, that's a good first step.
When you retrieve the tokens from storage, are they unchanged? Is it possible for them to get corrupted with the way you're managing them?
Put some logging in place to keep track of when tokens work and fail. Does a token ever start working again after it has failed once? If you fail to use a token for 30 days, does it expire? With a detailed log, you can start identifying the expired tokens and look for patterns in use to point to what might cause them to expire.
Be sure to explore other possibilities as well. How do users revoke tokens in Twitter? Is it easy to accidentally do that? For users with failed tokens, do they have other authorized apps that have stopped working as well?
First of all nice question Ran.
I want to ask you that have you gone through Twitter developers??
Sometimes it becomes ambiguous that which token to use since Twitter provides two pairs of tokens and the library.One of them is a secret key.
You need to select those token which starts with your Twitter ID followed by a hyphen.
Now your question is this error happens with some of yours users. So here is the answer that an app itself finds ambiguous to choose the token.
Though I might not be completely right, but I recommend you to try this solution at least once.
It might be possible these users have not revoked access. But in my experience an access token can also get expired after the user (in test cases: me) changed his/her password.
When the user does that, you can no longer use the REST API of stream API on that user's scope. Please adapt your application to handle with that situation. Revoke the user's session, so when he comes back to your application, he/she can be redirected to Twitter again to start a new OAuth access token process. Or send him/her an e-mail to kindly ask to reconnect. Vimeo/Windows/... are some of the people handling expired tokens with e-mails.
Have fun!
My God's answer is correct but I will share my answer from another question explaining how it could be your computer's clock:
If your OAuth flow was working one day and failing the next, check your computer's clock. I was running a Vagrant box that somehow had its time set to the day before, which caused the Twitter API to return {"code":89,"message":"Invalid or expired token."}. This may also appear as 401 timestamp out of bounds. You can use this command to update your clock in Ubuntu:
sudo ntpdate time.nist.gov
Alternative method if ntpdate isn't available on your system:
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
if your Access Token=738629462149844993-FcWHjfcucCLGEosyGGQ38qI******iC then don't forget to mention hyphen (-) followed by your USERID.
May be this will be helpful for you.I faced the same problem.
Please find the below piece of code snippet
$code = $tmhOAuth->user_request(array(
'method' => 'POST',
'url' => $tmhOAuth->url('oauth/access_token', ''),
'params' => array(
'oauth_verifier' => trim($params['oauth_verifier']),
)
));
if ($code == 200) {
$oauth_creds = $tmhOAuth->extract_params($tmhOAuth->response['response']);
// echo '<pre>';print_r($oauth_creds);exit;
$tmhOAuth->reconfigure(array_merge($tmhOAuth->config, array(
'token' => $oauth_creds['oauth_token'],
'secret' => $oauth_creds['oauth_token_secret'],
)));
$code = $tmhOAuth->user_request(array(
'url' => $tmhOAuth->url('1.1/account/verify_credentials')
));
}
The error invalid or expired token can be linked with the fact that one is not paying.
Without paying one will only be able to create the dev environment (sandbox).
As I have answered here:
Counts is only available to paid premium accounts, and one needs to pay for premium access.
Use this link to Apply for access.
Try to regenerate the keys again and save them properly.
For me, it happened because after regenerating one of the keys I did not update other keys. Therefore removed and regenerated all 4 keys again (CONSUMER_KEY, CONSUMER_SECRET, ACCESS_KEY, ACCESS_SECRET). And tried to execute it again and it worked this time.