I keep getting an invalid access token code 200 when searching the facebook graph with my valid app access token. I know there are some July breaking changes coming up, but I don't think this has to do with that.
https://developers.facebook.com/roadmap/
says that App access tokens will be required for all search Graph API calls except Places and Pages. Search for application will no longer be supported. I'm following the rules by searching public events with an app access token.
It may not be obvious, but it's documented at https://developers.facebook.com/docs/reference/api/search/:
Searches across page and place objects requires an app access token.
All other endpoints require a user access token.
You should use a user access token for search event.
If you think https://developers.facebook.com/roadmap/ is misleading, you should file a bug report at https://developers.facebook.com/bugs/create
Related
My end goal is to register my API to receive notifications of leads generated by LinkedIn for my business's Company Page. The docs here say I need to register at https://api.linkedin.com/v2/leadNotificationUrls using the r_ads_ge_automation permission. I'm trying to acquire this type of access token by using a web browser to hit https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=client_id_for_my_application&redirect_uri=https://my.company.net/api/oauth/linkedin&state=Testing12345&scope=r_ads_leadgen_automation, then logging in as a user that is an admin for the respective company page, then acquiring authentication code, and finally requesting an access token.
The problem is that when I try to hit https://www.linkedin.com/oauth/v2/authorization (with the query params above), I get an error response stating "r_ads_leadgen is not authorized for your application". I can't find any kind of application configuration that is supposed to give this permission to my application.
Can anyone help? Thank you
Permissions are offered to select Partners only. Have you applied to a Partner Program https://business.linkedin.com/marketing-solutions/marketing-partners/become-a-partner?
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
As per the querybuilder
My API URI looks:
https://www.googleapis.com/analytics/v3/data/ga?ids=ga:12134345&
start-date=30daysAgo
&end-date=yesterday&
metrics=ga:pageviews,ga:pageValue,ga:entrances&
dimensions=ga:pagePath,ga:daysSinceLastSession,ga:sessionCount,ga%3
Abrowser,ga:city&filters=ga:pagePath==/home
But when i execute in my domain, it throws error as login
required. So for that i also passed API-KEY as &key="****" to the
above url. But still no success. Still i get the same error
Am i missing something? Can i embed this results to embed-api in charts
The api key is different from the access token. If you use the Query Explorer you can check a box in the report to include the access token in the query URI, which will allow you to just paste it into your browser's address bar (note: access tokens expire after an hour).
If you want to learn how to get an access token programmatically, you should check out the OAuth 2.0 section of the Google Developers site:
https://developers.google.com/identity/protocols/OAuth2
I am working on a WordPress plugin that requires the use of OAuth 2. So far I've included the necessary OAuth files in an include folder in my plugin, put in the ClientId, ClientSecret I've obtained, and was able to authorize the app. After I authorized the app I received a callback code that I am supposed to use to get the token I assume. I put that code in my plugin, refreshed the page, and saw the information that is supposed to be outputted. When I go to a different page, it tells me that I am not authorized to view the information because the access token may be missing. So essentially it feels like the code that is sent to retrieve the token is only able to be used once. Do I need to store the token somehow? Any suggestions would be greatly appreciated.
In OAuth2 three-pass procedure the auth_code must be used only to obtain the access token
invoking a specific URL of the authentication server. The access token obtained can be used to access the pages later, as long as it is valid.
In LinkedIn API, the access tokens will be expired after 60 days, I want to refresh them in 60 days before they are expired in a console application. I viewed this document: https://developer.linkedin.com/blog/tips-and-tricks-refreshing-access-token, and I also viewed many posts in this forum, but it looks like the refresh flow is still now clear for me.
Please note that:
I need to refresh access tokens from a console application - it is not a website, it is a tool running in backend, it has no cookies and cannot open web page to ask user to login.
And if there are some sample code (not for website) that should be better, for example: C# or Java code.
You can use curl to accomplish this. For whatever programming language you use, there should be a relevant curl library.
The way this works is as follows:
You send a POST request to https://api.linkedin.com/uas/oauth/requestToken
You receive back a request token. Use that token in place of XXX in the following call: https//www.linkedin.com/uas/oauth/authenticate?oauth_token=XXX
You will receive the response you need, which includes the access token, which you need to save. It will not expire for the next 60 days.
If you could elaborate on the issues you're having, that would certainly help.
I see what you mean now. Linkedin doesn't allow you and will never allow you to do this. The reason access tokens expire is in order to add an extra layer of privacy protection for users. Linkedin would never want you to access user data if the user's aren't actively using your application. Of course, you might have a situation where no action is required on their part, that's the only drawback. Therefore, you would need to give them a reason to visit your application at least once in each token's lifetime.
I hope this helps.