I want to fetch the latest (public) status from our Weibo account and show it (reformatted and styled) on our website.
I can use the OAuth2 API, but that only provides a temporary auth token (and no refresh token). So whenever that expires (currently every day or two), I have to manually authorize and then add the auth token back into our web app.
There doesn't seem to be a way to get our latest public status without requiring an expiring auth token.
There are a few sites that provide RSS feeds, but they rewrite the content, and they seem flakey as well.
Is this basically impossible with Weibo, or am I missing something?
Related
I have iPhone application with an functionality of Login with facebook including few other functionalities related to graph API.
I receives facebook access token and save it to the server and server then makes further requests to graph API call from web end. As facebook access token expires after 60 days, I am getting access token expired error.
To solve this issue can i use FBSDKAccessToken.refreshCurrentAccessToken method to get new Access token ?
I did not find any clear idea for FBSDKAccessToken.refreshCurrentAccessToken.
OR Is there any other way to get new access token by performing automatic login with facebook from our application.
Thanks.
Native mobile apps using Facebook's SDKs will get long-lived access
tokens, good for about 60 days. These tokens will be refreshed once
per day when the person using your app makes a request to Facebook's
servers. If no requests are made, the token will expire after about 60
days and the person will have to go through the login flow again to
get a new token.
From the FB docs. ^
It seems the user will have to go through the login process in the app once again.
What exactly does the word "offline" mean with regard to the offline access granted by an OAuth server?
Does it mean that the resource server will return data about the user even when the user is logged out of the third-party application or when the user is logged out of the OAuth resource server such as Facebook or Google or Twitter?
Offline access is IMO a really bad name for it, and I think its a term only
Google uses its not in the RFC for OAuth as far as I remember.
What is Google offline access?
When you request offline access the Google Authentication server returns a
refresh token. Refresh tokens give your application the ability to
request data on behalf of the user when the user is not present and in front of
your application.
Example of an app needing offline access
Let's say I have a Super Awesome app that downloads your Google Analytics Data,
makes it into a nice PDF file and emails it to you every morning with your
stats. For this to work my application needs to have the ability to access
your Google Analytics data when you are not around, to give me permission to do
that. So Super Awesome app would request offline access and the
authentication server would return a refresh token. With that refresh token
Super awesome app can request a new access token whenever it wants and get your
Google Analytics data.
Example of an app not needing offline access
Let's try Less Awesome app that lets you upload files to Google Drive. Less
Awesome app doesn't need to access your Google drive account when you're not
around. It only needs to access it when you are online. So in theory it
wouldn't need offline access. But in practice it does, it still gets a refresh
token so that it won't have to ask you for permission again (this is where I
think the naming is incorrect).
Helpful quote from the OpenStack documentation:
If a refresh token is present in the authorization code exchange, then it
can be used to obtain new access tokens at any time. This is called
offline access, because the user does not have to be present at the browser
when the application obtains a new access token.
The truth about offline access
The thing is that in a lot of cases the authentication server will return the
refresh token to you no matter what: You don't have to actually ask for anything –
it gives it to you. Giving you the ability to access the users data when they
aren't around. Users don't know that you could access their data without them
being there. It's only the JavaScript library and I think the PHP library
that hide the refresh token from you, but it's there.
Example
By just posting (i.e. HTTP POST request):
https://accounts.google.com/o/oauth2/token?code={AuthCode}&
client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code
Here is the response:
{
"access_token": "ya29.1.AADtN_VSBMC2Ga2lhxsTKjVQ_ROco8VbD6h01aj4PcKHLm6qvHbNtn-_BIzXMw",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "1/J-3zPA8XR1o_cXebV9sDKn_f5MTqaFhKFxH-3PUPiJ4"
}
I now have offline access to this users data, and I never told them that I
would have it. More details be found in this short article: Google 3 legged
OAuth2 flow.
Useful reading
Using OAuth 2.0 for Web Server Applications
Understanding Refresh Tokens
By design the access tokens returned by the OAuth flow expire after a period of time (1 hour for Google access tokens), as a safety mechanism. This means that any application that wants to work with a user's data needs the user to have recently gone through the OAuth flow, aka be online. Requesting offline access provides the application a refresh token it can use to generate new access tokens, allowing it to access user data long after the data has gone through the OAuth flow, aka when they are offline.
Getting offline access is needed when your application continues to run when the user isn't present. For instance, if there is some nightly batch process, or if your application responds to external events like push notifications. However if you only access user data while the user is actively using your application then there is no need for offline access. Just send the user through the OAuth flow every time you need n access token, and if they've previously granted access to your application the authorization page will instantly close, making the process nearly invisible to the user.
For Google APIs, you can request offline access by including the parameter access_type=offline in the authorization URL you present to your users. Offline access, and hence refresh tokens, is requested automatically when using the Installed Application flow.
Goal
Fetch a company's updates save them locally in a background task
Problem
This should be done as a backend service without any real user interaction. We could provide a user account to use, but the authentication is a problem: There is literally no one to answer the OAuth redirect and there is no public redirect URL to configure, since it's a background service.
Is there any way to access the API without having a redirect URL or a real user?
You can get an initial access token in a regular front end flow, for you as the app developer i.e yourself as the LinkedIn user. Once you've got that, you can store it in the backend and use it for 60 days to get access to the LinkedIn APIs.
After 60 days you need to refresh the token as documented in:
https://developer.linkedin.com/documents/handling-errors-invalid-tokens
Unfortunately LinkedIn does not (yet) support an autonomous refresh flow where your app can get a new access token by presenting a refresh token on a backchannel. So the developer will have to refresh the access token by a manual login every 2 months.
Well, it is still all HTTP and HTML, so in fact there is no real reason to show the OAuth dialog to a user, as long you can strip out the necessary parts in the HTML authentication dialog and send a valid response back to the server, using the username and password from the user (which you can obtain from him, or save it yourself in a config file if it is you).
Note that there might be a legal issue if LinkedIn demands you to actually show the dialog, beside that, there is no technical need.
I want to make an application to fetch data from my Facebook page and display it in my application.
I tried using the Facebook API Explorer, it work fine but it expires after around 1 hour.
So, I need another way to get access to all my post like text, image and videos without expire data and anyone download my app can show my post without login to Facebook or any authentication.
Non-expiring Page Access Token are seemingly no longer possible with Graph API v2.0. If you have a v1.0 App, you could use the way described at Facebook non-expiring access token to get a non-expiring Page Access Token.
I have watched some videos on authenticating using oauth and have gotten the authentication part going but I have the following of questions.
Q1- Do access tokens expire?
Q2 -Do I have to make the user go through the whole user authentication process (with user authenticating the app again) once the twitter access token expires?
Q3-Is offline access to user's content possible once we have the access token
Ok so just to give some more context this is the scenario I have. Basically our mobile app is looking to integrate with twitter and there is a server side to it which needs to munch user's twitter feeds. And this is how we are thinking of doing it. Once the user authenticates our app using the mobile platform, we want to store this user access token in our server, poll his feeds at regular intervals and do some data munching on his feeds. For that we need
-Offline access to user's data
-Get a new access token without user's intervention if the previous one expires preferrably on the server side.
We don't want to have to go through user authenticating our app again.
The OAuth 2 spec is written in such a way that expired access tokens are a supported use case. Search for "expire" in https://www.rfc-editor.org/rfc/rfc6749 for example.
That said, the Twitter OAuth FAQ states:
We do not currently expire access tokens. 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.
To clarify, Twitter's use of OAuth is much more basic than Facebook's or Google's. For details and further help, Google is your friend. ;-)