We have a scenario as follows:

1. Fresh site install / instance using a Facebook app ID and secret that has been used on a prior install of the same site.
2. The logged-in user has already authorized the Facebook app to post on his or her behalf.
3. This instance has never posted for any users.

In this scenario, the first post we try to make does succeed but at the end we get redirected to a "Page not found" error. It looks like the URL is not being unescaped.

Here's a sample of the full URL:
fbautopost/authorization/retry?code=AQDrQmVOSjDsOYflDW--ho-XFZ-zpp5wdG9D6puQXDX5VLt2u2yYmu0cbjBKEj7l39krhQonXfWrxffLejEDnG0CXq38ALMxWtBPltxUaaScxRNALABF-78BwhYBxtLDVxxHinXBRyMqm4qjYs66WqVdzgFbR8ZF2B80o5F0AL4_MxgkgDrkUF5ZQFYyiCK8T_NFA9-KPaWd9dQxTAbV_RGshQiEvzaudunE69tTGSis4noWi-md8TgG0wW56LHLleGiLuGAfzWgM_jgLR0syancYol8PMDt5abh_uwrzycvCziNg12Aj4G3WoUipO_rSmY&state=1e601243605f35af6746266da2774923

One possible workaround would be to convert the code parameter to a menu path argument so that no escaping is possible. For example, the menu path could be changed from "fbautopost/authorization/retry?code=xxx&state=yyy" to "fbautopost/authorization/retry/code/xxx/state/yyy".

That should not require any unescaping, except for anything that Facebook might throw in that could be escaped.

Comments

GuyPaddock’s picture

Okay... I also see this behavior if 'retry' is set to 'TRUE' and the user skips adding the app but then later approves it in the same flow.

It seems like auto-post has an infinite loop of requesting approval if 'retry' is TRUE and the user 'Skips' granting the permission, until the user eventually wears down and approves it.

GuyPaddock’s picture

No longer seeing this behavior with the patch from #1911668: Redirection loop when retrying.

apaderno’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Active » Closed (outdated)
Issue tags: -URL encoding, -redirect, -facebook