I have a Magento 1.9 CE install which I am trying to access via the REST API.
I keep getting the 'oauth_problem=nonce_used' error when I start the process by calling the oauth/initiate URL.
I have added some logging into the /Mage/Oauth/Model/Server.php _validateNonce method and despite what nonce I supply in the Postman request, the same nonce gets logged out. In other words, the nonce in the request disappears somehow and a previous nonce is retrieved from somewhere.
And it isn't just the nonce from the previous request. I called the oauth/initiate URL several times and the logged nonce was the same for all of them (and never the nonce passed in the request).
I'm not sure if this is a Magento thing or Apache/mod_rewrite is doing something as well.
Any thoughts much appreciated.
It was an issue with Postman rather than Magento. It wasn't updating the post data correctly.
My application uses Outlook Push Notifications REST API to get updates for a set of users.
The code I use to make the registration is like following:
HTTP POST to:
https://outlook.office.com/api/v2.0/users/<user email>/subscriptions
POST data = {
'#odata.type': '#Microsoft.OutlookServices.PushSubscription',
'Resource': 'https://outlook.office.com/api/v2.0/me/messages',
'NotificationURL': 'https://<my_valid_hostname>/api/subscriptions',
'ChangeType': 'Created, Deleted',
'ClientState': <user UUID>,
}
This code always worked fine, but since Sep 26 it stopped to work for mostly of users. The HTTP request to make a registration to web notification returns HTTP 403 error:
HTTP 403 Error: https://outlook.office.com/api/v2.0/users/<user email>/subscriptions
{
"error": {
"code": "ErrorAccessDenied",
"message":"Access is denied. Check credentials and try again."
}
}
This application is a backend aplication registered in Azure AAD portal and uses a token which allow me to do the requests on behalf of the users.
My token credentials are working fine. I use the same token for Graph API and Outlook API without errors. I refreshed it to see if the error go away, but it doesn't work. The error comes for fresh tokens anyway.
For some users I get no error, it always work. The subscription is created fine and I get the subscription data in JSON returned, as usual.
This make me think that it may be a problem in Microsoft side, but I have no way to check this.
So how can I fix this error for the affected users?
First thing that comes in my mind is that did you forgot to renew your calendar subscriptions? It's something like max. 14 days those are alive. Anytime before expiration you can renew subscriptions and after that you still can revive subscriptions.
In fact now I tested new subscription with my app and I get only 7 days to expiration date.
At this point I got that you are getting error when creating new subscription.. are you sure your access_token is still valid?
For future SO users,
POST https://outlook.office.com/api/v2.0/me/subscriptions
Content-Type: application/json
Authorization: Bearer <access_token>
{
"#odata.type":"#Microsoft.OutlookServices.PushSubscription",
"Resource": "https://outlook.office.com/api/v2.0/<Outlook-Resource>",
"NotificationURL": "<My-Endpoint-Url>",
"ChangeType": "Created,Updated,Deleted"
}
Optional ClientState in body, allows the listener to check the legitimacy of the notification.
Check out the docs for more info.
Usually, Google OAuth2.0 mechanism is working great.
The user confirms permission to access Google account with selected scopes.
The refresh token is retrieved and saved to long time storage.
Each time needed (if the access token expired) access token is retrieved and used to access APIs.
But sometimes (thus far only two times for more than 6 months) I've experienced strange behaviour:
Requests to Google APIs return Invalid Credentials (401) error.
Refreshing the access token (using the stored refresh token) does not help.
Here is some structured output I've got when testing this issue:
+ ------------------------------------------------------------------------- +
| 1.TRYING TO REFRESH THE TOKEN. |
| 2.DONE REFRESHING THE TOKEN. |
+ ------------------------------------------------------------------------- +
| access: **************************************************** |
| refresh: ********************************************* |
| expires: 3600 |
| created: 2013-07-23 13:12:36 |
+ ------------------------------------------------------------------------- +
I've also tried to verify the "fresh" access token by sending requests to
https://www.googleapis.com/oauth2/v1/tokeninfo
+ ------------------------------------------------------------------------- +
| 1. TRYING TO CHECK THE TOKEN . |
| 2. DONE CHECKING THE TOKEN THE TOKEN. |
+ ------------------------------------------------------------------------- +
| issued_to: ************.apps.googleusercontent.com |
| audience: ************.apps.googleusercontent.com |
| user_id: ************ |
| expires_in: 3600 |
| email: **********#gmail.com |
| verified_email: 1 |
| access_type: offline |
| scopes:: |
+ ------------------------------------------------------------------------- +
| https://www.googleapis.com/auth/userinfo.email |
| https://www.googleapis.com/auth/userinfo.profile |
| https://www.googleapis.com/auth/plus.me |
| https://www.googleapis.com/auth/drive |
+ ------------------------------------------------------------------------- +
But when I try to access drive feed the response is:
Error calling GET https://www.googleapis.com/drive/v2/files (401) Invalid Credentials
domain: global
reason: authError
message: Invalid Credentials
locationType: header
location: Authorization
We also experienced the same issue with calendars.
So:
Token was valid before (everything worked).
Refreshing token still works.
Requesting a feed responds with "Invalid Credentials" error.
All the other tokens are still working great, meaning that the code is valid.
Normally when the token is revoked "invalid_grant" error is returned when trying to refresh the token.
Questions
What can be the reason for this behaviour? If the refresh token was revoked or got invalid in some other way, should the request for new access token produce error?
Is there a way to validate the refresh token?
Per the Google API docs on errors & error codes:
https://developers.google.com/drive/handle-errors#401_invalid_credentials
401: Invalid Credentials
Invalid authorization header. The access token you're using is either expired or invalid.
error: {
errors: [
{
"domain": "global",
"reason": "authError",
"message": "Invalid Credentials",
"locationType": "header",
"location": "Authorization",
}
],
"code": 401,
"message": "Invalid Credentials"
}
}
This matches your version of the error exactly, and so is very probably what Google thinks is wrong with your request.
But, as you well know, Google API requests can return errors that are distinctly unhelpful to actually diagnosing the problem. I have gotten "Invalid Credentials" errors for a number of reasons. It is almost always really because I have made some sort of change that I thought would not matter, but really does.
My first thought (shot in the dark here) would be to go to the Google API console:
https://code.google.com/apis/console
Googles auth token verifier ( https://www.googleapis.com/oauth2/v1/tokeninfo ) can return a valid response, but maybe the client secret or client id will have been changed.
Even tiny changes in the response body can also cause this error.
I don't know how you are making requests, whether by REST calls or a client lib, but I use the ruby lib which allows a command line interface to making API calls. I have found this & the OAuth2 Playground very helpful in diagnosing Google API calls.
Just an FYI: I have only gotten 2 errors from the Google API: "Invalid Credentials" and "Insufficient Permissions". The latter has almost always had to do with bad scopes. The former is just about everything else.
I would also say that if you have only experienced 2 errors in 6 months, you are lucky!
I had this problem when I tried experimenting with changing the redirect url in google console and then updating my json credentials file on server. I had to clear the session variables before starting afresh. So in your project just do this once:
session_start(); //starts a session
session_unset(); //flushes out all the contents previously set
Remember to remove the session_unset() after dry running it once.
I'm on Development environment. I had this problem too.
First I tried refreshing the credentials. No result. Then I deleted my app (since I'm still on development enviroment, that was ok, but BE CAREFUL WITH THIS ACTION if you're already using this on production), created a new one, updated the credentials JSON on the client... still, no result.
I solved it by opening on a new browser instance which wasn't logged in my Google Account (Private Browsing, since I'm on Firefox), logged on my Google Account once again, and tried using my client (which is a Web Application). I was redirected to the authorization screen as expected and after that, it worked fine for me.
Maybe this behavior is due to a limitation which Google describes as follows:
There is currently a limit of 50 refresh tokens per user account per client. If the limit is reached, creating a new token automatically invalidates the oldest token without warning. This limit does not apply to service accounts.
There is also a larger limit on the total number of tokens a user account or service account can have across all clients. Most normal users won't exceed this limit but a developer's test account might.
I recently experienced this weird error. My fix: I put the function that unsets all of the sessions before redirecting to AuthUrl.
clearing storage in Google Chrome worked for me (don't know all the details of what 'Clear storage' is clearing):
F12 (Ctrl+Shift+I)
Application Tab
Clear storage
I had the same problem with this error:
The redirect URI in the request, does not match the ones authorized for the OAuth client.
But found this very simple solution by abhishek77in here:
https://coderwall.com/p/fmr5ag/avoid-invalid-credentials-with-google-oauth2
The solution is:
If you are using
https://github.com/zquestz/omniauth-google-oauth2 make sure to
follow the note in README. "You must enable the "Contacts API" and
"Google+ API" via the Google API console."
Enabling these in the Google API console fixed the "Invalid credentials" problem for me.
userInfo: Invalid Credentials
I got the following error because the scopes array elements i was trying to access ie profile and email whose links I got from google+ api scope page: came to be somehow false/invalid so I went to my consent screen and there
under Scopes for Google APIs was mentioned email profile openID on hovering on each I got there respective urls replacing my old ones with these resolved my error
I received (401) Invalid Credentials when I removed the access to my Google Account for the particular app. So what I had to do was to request the authorization URL (the one which starts with https://accounts.google.com/o/oauth2/auth), again.
I ran into this same problem when I needed to change my scopes from Read Only to Read And Write All Files. So, I updated my scopes from at the top of my file from Read Only to:
// If modifying these scopes, delete your previously saved credentials
// at ~/.credentials/sheets.googleapis.com-nodejs-quickstart.json
var SCOPES = ['https://www.googleapis.com/auth/drive'];
Google, from their API guide, has these comments that say whenever you change scopes, you must update credentials. I believe this means, although I am not certain, that the token must be updated. The old token is still held by Google and it thought that I only had Read Only access, hence why it would return a 401 error. So, I need to remake my token, but Google never offered a new consent screen that would allow me to say allow Read And Write To All Files. So, I needed to get that screen to come up again, so it would create a new token to replace the old one:
fs.readFile(TOKEN_PATH, function(err, token) {
if (err) {
getNewToken(oauth2Client, callback);
} else {
getNewToken(oauth2Client, callback);
// oauth2Client.credentials = JSON.parse(token);
// callback(oauth2Client);
}
});
Since I already had a saved token, it was never creating a new one. So, I just commented out the using of the old token and told it to get a new token, no matter if we have one or not. Then, I went to my Connected Apps in Google and deleted my old connecting credential. I'm not sure if this step is necessary, but I am only trying to access my personal account. Then, when I ran my program, it prompted me to re-authenticate, and everything worked and I did not receive an authentication error. Once done, make sure to remove the commented out lines for using already made tokens. I was using the Google API quickstart.js file for all of this.
So, when I updated my scopes, the old token was still using the Read Only scope, therefore I would get (401) Invalid Credentials.
I resolved this problem when I removed files json in c:\Users\[user]\.credentials.
Maybe this is helpful to someone:
I had a similar issue using the JavaScript Google-API client for Calendar API. At random times it would work but mostly I got the same error. Adding scopes, testing key, nothing helped. After a few hours I found this solution, no idea why it works but it solved the issue for me:
gapi.client.init({
'apiKey': API_KEY, <-- DOESN'T WORK
'clientId': CLIENT_ID,
'discoveryDocs': DISCOVERY_URLS,
'scope': SCOPE
}).then(function() {
// gapi.client.setApiKey(API_KEY); <-- ADD THIS
})
If you're using an account that's part of a GSuite set up, you might need to add GSuite Basic to the account. You get to this by Users > Click on user > Licenses.
I am not able to get a request token from the oauth/initiate page because it says page not found. What could be the problem?
I have created an oAuth customer, given the appropriate REST roles and attributes. Also, appended the consumer key, secret, nonce etc. in the authorization for the oAuth request.
What am I missing?
Oauth will give you page not found if the request params are incorrect. It's likely your client isn't sending the parameters correctly, or your signature doesn't match the one Magento is calculating.
I added some temporary logging to the OAuth server to try and track down the issue.
Add this to file app/code/core/Mage/Oauth/Model/Server.php after line 594, it will help you see what specific oauth error is being raised
Mage::log($response, Zend_Log::DEBUG, 'oauth.log');
Try your initiate request again, and then check var/log/oauth.log to see what the error is.
Don't even think about doing this on a production system, and ensure you roll back your changes afterwards. You should never modify core files other than for temporary debugging.
I have read the page on implementing OAuth that Twitter have written. I've registered my app, it will only access my account, so I skip all the request token stuff. I have, from the "Your apps" page:
consumer token
consumer token secret
access token
access token secret
I write some ruby code and test its output against Beginner’s Guide to OAuth (suggested reading in the Twitter docs). I get the same output, i.e. the signature, the base string and the Authorization headers are identical.
However, when I connect to the Twitter Rest API and try the verify credentials command the response is invariably "Incorrect signature".
I try using different code (very similar to mine) from a gist by erikeldridge on github but it doesn't work either. Instead of connecting via cURL (using the curb library) I use Net/Http - same error response is returned.
I change over to using the OAuth gem. It uses Net/Http to connect. Same error response comes back.
Verify credentials isn't the only command I've tried to use in the API, but they all give the same error, whether it's GET or POST, requires extra params or not. I've been using the Search API successfully using the curb library without problems so I don't think it's the connection method.
What might I do to fix this?
Ruby 1.9.2; cURL 7.21.2; oauth 0.4.4; curb 0.7.8; json 1.4.6; OSX 10.6.5;
Even though your application is only accessing your data, you can't simply 'skip the request token stuff'. The request token is integral to the OAuthentication process.
Summarised, the 3 main parts of the OAuth process are as follows:
Get Request Token Key and Request Token Secret
Use Request Token to authorise application to access your data. This will provided the user(you) with a PIN
Use the PIN to exchange the Request Token and Secret for an Access Token and Secret.
A more detailed OAuthentication flow can be found here.
It's fixed - I regenerated the Consumer key and secret on the Twitter site and it started working. I've no idea why the previous set didn't work - the code was solid (works all the time now) and the details were correct. Perhaps they (Twitter) could provide more detailed error messages? But I'm happy :)