Nowadays both twitter and faceboox are very strict on what url they will return to, they will not accept url with varying targets. e.g ?Target=/some/page. They only accept returning to an exact url you specify.
So any target needs to be stashed beforehand. and applied from a known return url. Which requires some development.
Hi Adrian - I have the same error message when trying to set up a Facebook login for my site:
{
"error": {
"message": "Can't Load URL: The domain of this URL isn't included in the app's domains. To be able to load this URL, add all domains and subdomains of your app to the App Domains field in your app settings.",
"type": "OAuthException",
"code": 191,
"fbtrace_id": "BpTGQLBfgNb"
}
}
Unfortunately the OAuth redirect url has to be very specific, that includes any path and query parementers
Since it not possible to set every possible variation due to Target parameter, etc this error is likely to come up.
I'm not using the core plugin, but I have taken this into consideration with a custom implementation. So I can't comment on any change if any they have made, however my approach is to stash the target and redirect to a set in stone url only.
Even stashing work differently in newer version of vanilla, especially if you want to carry over from not singed in to signed in. So I needed a custom implementation of that too.
when a sign in wants to return to a whatever page you are where on that location is not a single location, it varies.
Facebook or Twitter does not accept this scenario any more, so that variability has to be suppressed first so could can return to a known url which doesn't vary.
You can't put every possible url it is not practical. It has to return to a single url and any forwarding come from a stashed value. Stashing has to survive between not signed in to signed in.
I could go through the technical details but frankly I don't have time, it is up to those maintaining the plugin. You might make an issue on github.
Again I haven't check what changen have been made to address this if any on the codebase. Given that the current core don't even support this type of stashing method through Gdn:session()->stash() as I found the hard way, I suppect this has been overlooked.
Sometimes where app account on Twitter or Facbook were created before a change the continue to operate as ther always did, so unless they are made aware, they might not realise this is an issue till they need a new app.
Comments
next?
Nowadays both twitter and faceboox are very strict on what url they will return to, they will not accept url with varying targets. e.g ?Target=/some/page. They only accept returning to an exact url you specify.
So any target needs to be stashed beforehand. and applied from a known return url. Which requires some development.
grep is your friend.
Hi Adrian - I have the same error message when trying to set up a Facebook login for my site:
{
"error": {
"message": "Can't Load URL: The domain of this URL isn't included in the app's domains. To be able to load this URL, add all domains and subdomains of your app to the App Domains field in your app settings.",
"type": "OAuthException",
"code": 191,
"fbtrace_id": "BpTGQLBfgNb"
}
}
My Facebook login settings as follows:
Site is:
Unfortunately the OAuth redirect url has to be very specific, that includes any path and query parementers
Since it not possible to set every possible variation due to Target parameter, etc this error is likely to come up.
I'm not using the core plugin, but I have taken this into consideration with a custom implementation. So I can't comment on any change if any they have made, however my approach is to stash the target and redirect to a set in stone url only.
Even stashing work differently in newer version of vanilla, especially if you want to carry over from not singed in to signed in. So I needed a custom implementation of that too.
Unfortunately change can be blunt.
grep is your friend.
Hi xOO - thanks for the response. Any suggestions on what URL I should use?
there isn't an url you can use that is the point.
when a sign in wants to return to a whatever page you are where on that location is not a single location, it varies.
Facebook or Twitter does not accept this scenario any more, so that variability has to be suppressed first so could can return to a known url which doesn't vary.
You can't put every possible url it is not practical. It has to return to a single url and any forwarding come from a stashed value. Stashing has to survive between not signed in to signed in.
I could go through the technical details but frankly I don't have time, it is up to those maintaining the plugin. You might make an issue on github.
Again I haven't check what changen have been made to address this if any on the codebase. Given that the current core don't even support this type of stashing method through
Gdn:session()->stash()as I found the hard way, I suppect this has been overlooked.Sometimes where app account on Twitter or Facbook were created before a change the continue to operate as ther always did, so unless they are made aware, they might not realise this is an issue till they need a new app.
grep is your friend.