现在已不赞成使用offline_access来处理服务器端身份验证？

Question

With the impending demise of access tokens with no expiration I am hoping someone can help with my rather unique problem.

I've read all of the documentation surrounding https://developers.facebook.com/roadmap/offline-access-removal/

And I think my application falls into an entirely different category. We have an application that posts messages to facebook rarely (it could be years between them) ,but the postings are quite important. These postings are initiated within a JVM running tomcat, but are not necessarily initiated by anything a user does.

When the user installs their version of the application they go through the normal server-side authentication process using a browser

https://graph.facebook.com/oauth/authorize?client_id=APP_ID&scope=publish_stream,manage_pages,offline_access&response_type=token&redirect_uri=MY_REDIRECT_URL

Historically my application then stores the access token generated (which never expired) in a database. Now, with the offline_access deprecation, this access token is now a short-lived token which apparently can be exchanged to a 60 day token by going to

https://graph.facebook.com/oauth/access_token?client_id=AP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=OLD_SHORT_TOKEN

So I could go to the above URL and store the long-term access token returned. So far, so good. Here's the problem....

As stated earlier, my application might not try to post to facebook for months or years (ie after my 60 day token has expired). According to the documentation I can use the fb_exchange_token option to exchange a short-lived token for a 60 day token, but I can't exchange a 60 day token that is about to expire for a new 60 day token. And the only way I have found to get a new short-lived token is by having the user log in and generate it. That's my problem. As I understand it I can't get the new short-lived token without having a user log in again.

I was trying to think of an analogy that would be simpler to understand and this is the best I've come up with.

Assume I have a bash script that runs in cron every 90 days to post a message to a company's facebook page announcing that the quarterly reports are available. In the new, deprecated offline_access world how could I make this cron job work? The only customer-specific data I store is a 60 day access token and the bash script has no user interface.

If I did the hackiest solution and required the person who installed our application to include their fb username and password as part of the installation how would that even work. Is there a way to provide the username and password to the graph api and then simulate logging in and oauth click streams with something like HttpClient?

Ideally if I had something like fb_exchange_token option that could exchange a 60-day token for a new 60-day token I could write something that samples facebook once a day to see how close my 60-day token is to expiration and when it gets within a day or two perform a new fb_exchange_token and save the new 60-day token.

Sorry if this is a wordy posting. I tried to get all of the info out there so someone could help without having to ask followup questions.

Answer 1

As I understand it I can't get the new short-lived token without having a user log in again.

Well, that's the whole point of removing offline_access …

Assume I have a bash script that runs in cron every 90 days to post a message to a company's facebook page announcing that the quarterly reports are available. In the new, deprecated offline_access world how could I make this cron job work?

With a page access token instead of a user access token – page access tokens don't expire (as long as the user you've got them from does not change his password or leaves the platform completely).

If I did the hackiest solution and required the person who installed our application to include their fb username and password as part of the installation how would that even work.

That would be a clear violation of FB Platform Policies. You should not even consider doing that.

Ideally if I had something like fb_exchange_token option that could exchange a 60-day token for a new 60-day token […]

Again, if Facebook would want that to be possible, they would not have needed to remove offline_access in the first place.