You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Facebook is rolling out a new page experience. This requires the people to use a page access token when calling the majority of page related access points.
In order to get a page access token, you must first have a user access token, and optionally exchange that for a long-lived user access token first.
While this is a bit too service-specific, I wondered if we should have some sort of Facebook Page extended service, to handle the exchange of these tokens. It would probably need to hold a reference to the user access token (although that's up for debate), but overall I'm not sure how this flow would fit into the current Keyring architecture.
It's probably a case of overriding the methods that handle the OAuth flow and construction of the metadata, but as it's not standard OAuth, it doesn't seem to cleanly fit into the current implementation of services.
I need to give it some more thought, but as a first step, created this issue so we could discuss the best way forward. I'd be interested to hear your thoughts @beaulebens.
The text was updated successfully, but these errors were encountered:
Facebook is rolling out a new page experience. This requires the people to use a page access token when calling the majority of page related access points.
In order to get a page access token, you must first have a user access token, and optionally exchange that for a long-lived user access token first.
While this is a bit too service-specific, I wondered if we should have some sort of Facebook Page extended service, to handle the exchange of these tokens. It would probably need to hold a reference to the user access token (although that's up for debate), but overall I'm not sure how this flow would fit into the current Keyring architecture.
It's probably a case of overriding the methods that handle the OAuth flow and construction of the metadata, but as it's not standard OAuth, it doesn't seem to cleanly fit into the current implementation of services.
I need to give it some more thought, but as a first step, created this issue so we could discuss the best way forward. I'd be interested to hear your thoughts @beaulebens.
The text was updated successfully, but these errors were encountered: