The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.fboauth doesn't support a user revoking access to an app from Facebook when that app has a deauthorise callback defined. I've attached a diff that provides that support which works for my situation.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | fboauth_deauth-d6.patch | 6.79 KB | quicksketch |
| #7 | fboauth_deauth-d7.patch | 6.73 KB | quicksketch |
| #6 | fboauth_1441758_6.diff | 5.26 KB | darrylh |
| #4 | facebook-deauth-url.png | 76.61 KB | darrylh |
| fboauth-signed-request.diff | 2.66 KB | darrylh |
Comments
Comment #1
quicksketchCould you describe what you're expecting to happen when the user deauthorizes the app via Facebook? Right now if you deauthorize the app and try to log in via FB OAuth, the module simply requests access again from Facebook. That seems like a pretty logical behavior to follow. Or is this callback intended to be pinged by Facebook when the user deauthorizes? I'm just not sure how I should test this patch and what functionality it's intending to provide.
Comment #2
darrylh commentedYeah, this is responding to the ping from Facebook when the user revokes the access from Facebook.
Testing it will be along the lines of
1) Connecting from Drupal
2) Confirming access at the Facebook end
3) Revoking access from the Facebook side (http://www.facebook.com/settings?tab=applications, or the down arrow menu at the top right, account settings, apps)
4) If my other patch is applied (#1441752: Provide link to connect a Facebook account from the user edit page), going to the settings page should show the connect button/text rather than the deauthorisation button/text
Hopefully that makes more sense :)
Comment #3
quicksketch#1441752: Provide link to connect a Facebook account from the user edit page is already committed and in the 1.5 version that is out now.
From looking at your code, I can't tell how it's supposed to work. It seems like at the very least we'll need to document how to use this in the README.txt file. What's the URL that a user should give Facebook for deauthorization? And where do they enter that URL in their Facebook app settings?
Comment #4
darrylh commentedThe deauthorisation URL is part of the advanced app settings - I've attached a screenshot showing where it is.
When a normal user revokes/deauthorises an app from Facebook, a POST request is sent to that URL. The payload of that request is a Signed Request (https://developers.facebook.com/docs/authentication/signed_request/), which contains the users Facebook id, among other information.
My patch then looks for that user via the fboauth_users table, and if the mapping is accurate, unlinks the user. I set the URL to the deauth action as that seemed like the right place to put it. If it should be somewhere else, please move as appropriate.
Perhaps of some note, Facebook doesn't seem to care whether the signed request is dealt with or not - I've sent it to a URL that returned a 404 error and the deauthorisation still went ahead of the Facebook side.
Comment #5
quicksketchThanks for the clarification. I think it would be wise for us to make a new menu callback for deauthorization. Just throwing it into our existing action callback doesn't make much since, as it's a completely different operation that doesn't require authorization from the user at all.
It would also be good to provide a new hook (say hook_fboauth_user_deauthorize()) to allow other modules that used FBOAuth to collect data to clean up data that may no longer be necessary or desired.
And we still need to document this functionality in README.txt.
Comment #6
darrylh commentedI've attached another patch that hopefully addresses your last comment. It's patched against 1.4 as 1.5 isn't available to download (at least for me.)
A couple of notes - I've not created hooks before, so I'm not sure it's correct, and my documentation could probably do with some tweaking (or rewriting.) The menu item access is set to TRUE because the Signed Request comes from Facebook directly, rather than via the users' browser, so any sessions in play won't be relevant.
Comment #7
quicksketchI've rerolled these patches with a few changes:
- Ported to D6.
- Changed the hook name to hook_fboauth_deauthorize() rather than hook_fboauth_user_deauthorization() for consistency with hook names and with Facebook's verbage.
- Cleaned up code for coding standards.
- Removed documentation around intricacies of Facebook's APIs, which weren't relevant for end-users.
Overall this is a great patch! I'm stuck waiting for a DNS change so that I can confirm this callback works properly with requests for Facebook, but assuming this works it's ready to go. I'll commit it as soon as I can confirm it works properly.
Comment #8
quicksketchI've confirmed these patches work. Thanks so much! Committed to both branches of the project.