Environment:
TryPost: self-hosted, latest main
Meta app: created via the "use case" flow (Manage everything on your Page)
Facebook OAuth scopes requested: pages_show_list, business_management, pages_manage_posts, pages_manage_engagement, pages_read_engagement, read_insights
Description:
The Facebook connect flow behaves inconsistently depending on which option is chosen in Facebook's own consent dialog:
Choosing "Enable all current and future Pages": the connection succeeds, but TryPost always connects the first Page in the account's Page list (e.g. "Wound Academy" in my case), regardless of which Page I actually want to use. There is no page-picker shown afterward.
Choosing "Select specific Pages" and picking a Page that is not the first one in the list: the connection fails with the error "No Facebook page found. You must be an administrator of at least one page." — even though I am an admin of that Page and explicitly selected/authorized it in Facebook's dialog. (Selecting the first Page in "specific Pages" mode works fine.)
Steps to reproduce:
In TryPost, click "Connect" on Facebook.
Case A: choose "Enable all current and future Pages" → complete OAuth → observe the first Page in the account gets connected instead of showing a picker.
Case B: choose "Select specific Pages", check a Page that is not first in the account's Page list → complete OAuth → observe the "No Facebook page found" error, even though that Page was explicitly authorized.
Expected behavior:
TryPost should connect (or let the user pick from) the Page(s) actually authorized during the Facebook consent flow — not just the first Page in the account, and not fail when a non-first Page is explicitly selected.
Actual behavior:
"All pages" mode → silently connects the wrong (first) Page.
"Specific page" mode with a non-first Page → fails with "No Facebook page found", suggesting TryPost's handling of the /me/accounts response (or of the granular page-scoped token) only recognizes the first Page in the list, regardless of which Page(s) were actually granted.
Additional notes:
This points to the Facebook OAuth callback likely indexing into /me/accounts by position (e.g. [0]) rather than matching against the Page(s) actually returned/authorized. Happy to provide logs/screenshots if helpful.
Environment:
TryPost: self-hosted, latest main
Meta app: created via the "use case" flow (Manage everything on your Page)
Facebook OAuth scopes requested: pages_show_list, business_management, pages_manage_posts, pages_manage_engagement, pages_read_engagement, read_insights
Description:
The Facebook connect flow behaves inconsistently depending on which option is chosen in Facebook's own consent dialog:
Choosing "Enable all current and future Pages": the connection succeeds, but TryPost always connects the first Page in the account's Page list (e.g. "Wound Academy" in my case), regardless of which Page I actually want to use. There is no page-picker shown afterward.
Choosing "Select specific Pages" and picking a Page that is not the first one in the list: the connection fails with the error "No Facebook page found. You must be an administrator of at least one page." — even though I am an admin of that Page and explicitly selected/authorized it in Facebook's dialog. (Selecting the first Page in "specific Pages" mode works fine.)
Steps to reproduce:
In TryPost, click "Connect" on Facebook.
Case A: choose "Enable all current and future Pages" → complete OAuth → observe the first Page in the account gets connected instead of showing a picker.
Case B: choose "Select specific Pages", check a Page that is not first in the account's Page list → complete OAuth → observe the "No Facebook page found" error, even though that Page was explicitly authorized.
Expected behavior:
TryPost should connect (or let the user pick from) the Page(s) actually authorized during the Facebook consent flow — not just the first Page in the account, and not fail when a non-first Page is explicitly selected.
Actual behavior:
"All pages" mode → silently connects the wrong (first) Page.
"Specific page" mode with a non-first Page → fails with "No Facebook page found", suggesting TryPost's handling of the /me/accounts response (or of the granular page-scoped token) only recognizes the first Page in the list, regardless of which Page(s) were actually granted.
Additional notes:
This points to the Facebook OAuth callback likely indexing into /me/accounts by position (e.g. [0]) rather than matching against the Page(s) actually returned/authorized. Happy to provide logs/screenshots if helpful.