Access tokens with Graph Api stopped working even after upgrading to API 2.0 - api

my app was pulling feeds to my site for over a year, and recently stopped working late this month(23/03/2015).
I debugged the application, and still don't know why my access token is reported malformed. Here is a sample of a token which to me perplexes me as at the end there is a # tag in it, something I don't expect with QueryString access tokens:
AQD2pAp0kqILBZ9ysXGarDVdmcnnknRgnLvnLdml2TuiLXH8grq8mHkyBCE3jjoEahyMl17myD7ldp1DDWRYEIP9EEnwSHUU5-sZk3mZv6p5YTLpfTVQntYeuuYbIYEn13e3PkF2_cCQbRU2R769xr_Cj0j3Gf_HygWElOQq3BtivxTgN4Db1HfEzrIpnR7309sAZAwKJKbTGw07KukL51oVn1di0gcO2dn5ffv5V4MEb4RuVLLNrcjZWbVPB7Ktyiy62Gw-64ypMqyx2zj_0quZKFlgV0fBE_TY3K_iMr-XEGuodId1hk0n7k89DUjXa40#=
Looking at my application on Facebook(app), it is clear that I should expect access tokens on request from Query String.
Something is definitely wrong, as this access token reports a malformed access token. This is a recent bug that has just cropped up so I think.
Any body know about this problem? I can't access my feeds from my facebook profile using this access token to expose to my web based application.
Any help or suggestions are welcome.
Kind regards
Martin Okello.

Probably, you were using the read_stream permission which is no longer granted to apps. You should try to regenerated an Access Token with the new user_posts permission and use this Access Token instead.
See
https://developers.facebook.com/docs/apps/changelog#v2_3_new_features
https://developers.facebook.com/docs/facebook-login/permissions/v2.3#reference-read_stream

Related

Exact online REST API: POST call not working

I am trying to make a post call in Exact Online REST API. I'm trying to create a SalesInvoiceLine. I can perfectly do a GET call via my browser. I am logged in in Exact Online so I don't need authentication since this should be passed via a cookie. I tried POST via a browser. The browser prompts me to login, when I do nothing happens. I've also tried this in Postman:
I am 100% certain these initials are correct, I can login with them in Exact Online. What am I doing wrong?
If this is not the way, how can I post data to Exact Online? There are not that many concrete examples to find online.
You can't log on to the Exact Online REST API with Basic authentication, the mode you are using now.
The web service uses OAuth as authentication mechanism, meaning you have to acquire a token first. The steps to do so are outlined in the official documentation.
It will need some work on your end to register an app, get the flow up and running. Depending on your business needs, you might be helped with one of the apps for Exact Online by the company I work for.
You need to retrieve the CurrentDivision through GET Request https://{Base Uri}/api/v1/current/Me only from OAuth then you need to assign
CurrentDivision to whatever may be the API call .../api/v1/{CurrentDivision}/../....
Without authorization by Auth 2.0, neither is impossible.
To authorize the ExactOnline API calls you have to do the following:
Register the app in the developer portal. Bear in mind that you have to do a separate registration for French, UK or Dutch version of ExactOnline (this is indeed a pain).
In case you want your application to be used by other accounts than yours, you have to submit the app for validation, this usually takes 2-3 weeks.
EO uses standard OAuth 2.0 schema (very similar to what Google is using with their services). You have to use endpoint GET /api/oauth2/auth for building an authorization link and endpoint POST /api/oauth2/token for obtaining both access and refresh tokens.
Please bear in mind that many Auth 2.0 services are proving long-lasting refresh token. This is not the case of EO. The refresh token is invalidated every time when the access token is requested (endpoint POST /api/oauth2/token). With access token new refresh token is supplied, so make sure you update you refresh token as well.
The access token is placed in HTTP header as "Authorization: Bearer {{ACCESS_TOKEN}}"
In case you want to automate the EO API calls and do not want to code anything on your own, you can try one of the pre-build Exact Online API connectors, created by the company I work for.

Adobe Sign access token invalid_request

I'm having trouble with Adobe Sign's OAuth authentication -- every time I try to get my access token with my Client ID and redirect URI, I get this message:
Unable to authorize access because the client configuration is invalid: invalid_request
This is the request that I have been making (with the proper substitution for REDIRECT and CLIENTID):
https://secure.echosign.com/public/oauth? redirect_uri=REDIRECT& response_type=code& client_id=CLIENTID& scope=user_login:self+agreement_send:account
I am fairly new to OAuth and don't understand what I'm doing wrong. Could someone please explain the issues that could result in this error message?
I was having the same problem. I solved it by including the correct shard in the URL after "secure." and before ".echosign". You identify your shard by looking at the URL where you created your application.
I found this information here.
Hope this helps.
Is OK to have spaces in that https request?
If you still have a problems with this.
I think your URL is not correct.
I using this one
https://secure.na2.echosign.com/public/embeddedWidget
for adobe widget.
Adobe require same url for OAuth
https://secure.na2.echosign.com/public/oauth
Check your domain, and try. You can create widget just to see your domain
This comment might get helpful for others who are facing issue in Adobe Sign access token invalid_request.
Developer Guide on Sign API: https://opensource.adobe.com/acrobat-sign/developer_guide/index.html
For the Outh process and the link to be used in user's browser:
https://secure.na1.adobesign.com/public/oauth/v2?redirect_uri=https://www.google.co.in&response_type=code&client_id=paste_your_client_id_here&scope=user_read:account
If any one using sandbox,
https://secure.na1.adobesignsandbox.com//public/oauth/v2?redirect_uri=https://www.google.co.in&response_type=code&client_id=paste_your_client_id_here&scope=user_read:account
Please ensure the correct environment identifier and shard. https://helpx.adobe.com/sign/using/identify-account-shard.html
https://helpx.adobe.com/sign/kb/unable-to-authorize-access-because-the-client-configuration-is-invalid-invalid-request-while-running-oauth-process.html
After pasting URL in browser and allowing the access to your API and getting code. Please use endpoint URL to get access token as below:
for developer account: https://api.na1.adobesign.com/oauth/v2/token
for sandbox account: https://api.na1.adobesignsandbox.com/oauth/v2/token

Generate Permanent Instagram Access Token

We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)

LinkedIn grant access screen showing even though user already authenticated

I'm using an external Node.js module, everyauth, to handle my LinkedIn API authentication. I'm not yet positive if this is a problem with the way my module handles their API, or some other API issue itself.
Basically, after a user has already granted access, LinkedIn nevertheless continues to ask whether to continue to grant access. I know this is not standard because I've seen a different user flow in other applications.
Here's an example of what happens:
You can see I granted access on Jan 11th, but this was taken on Jan 13th. Why must I re-auth!?
Do you have any idea what is causing this? I dove into the relevant LinkedIn module code for everyauth but nothing in that application flow caught my eye as the problem.
Modify the script to send them to https://www.linkedin.com/uas/oauth/authenticate instead of
https://www.linkedin.com/uas/oauth/authorize.
That will cause LinkedIn to automatically redirect them back to your site.
See more at https://developer.linkedin.com/documents/linkedins-oauth-details
If you are using the JavaScript API (which it looks like everyauth uses), then it is likely that the OAuth tokens that LinkedIn stores in the browser have become 'stale'. To ensure that the user is the correct user, the browser tokens expire after ~30 minutes.
That being said, if the session is still fresh and the authorize value is set to true, you should be able to bypass the screen you are seeing.
https://developer.linkedin.com/documents/overview

UserAuthentication via Flattr-REST: No PIN returned?

I'm trying to write a new application using the Flattr REST-API version 1 (not the beta v2). The application acquires a request token at first, which seems to work properly. But I run into a problem authenticating the user. The link created for authentication looks like this:
https://api.flattr.com/oauth/authenticate?access_scope=read,click&oauth_token=MY_REQUEST_TOKEN
Clicking the link everything seems alright. Information about the application and the scope requested is shown, but clicking "Authenticate", there's no pin code, but the following error from https://flattr.com/apps/pincode/MY_REQUEST_TOKEN:
Something went wrong. Please try again
BUT now the Application IS in the authorized application list of the user though that doesn't really help if the user can't get the pin code...
The Application type is set to client. It's the first time I try to work with the API so I'm not sure if I miss anything important? Would be grateful for some help.
Just as an update: We finally changed to API v2. Getting Authorization for our application feels a bit clumsy, as we set the redirecturi to some webpage, where we display the returned code and let the user copy&paste it into our client application... we kind of made our own pincode-flow :/
If possible, please use the v2 api, which uses oauth2 + bearer token.
However, the new API doesn't support authentication using the pincode flow.
As stated by Maike this is probably a bug that has surfaced yet again :(
I'll create an internal bug ticket and try to get it fixed.
The pincode isn't a feature planned. You can use the oauth2 "implicit grant" to authenticate the resources owner. This isn't documented at the moment but is possible.
When you do the request to https://flattr.com/oauth/authorize you pass the response_type token instead of code. This will append a access_token fragment in your callback URL. In your http client it might be possible to catch the 302 from our server and parse the access_token from the fragment.
All this requires a http client in your application whom you can control the flow inside your app.