or it could be that one or the other must be disabled . If both are enabled it could cause conflicts. it could be all of the above in various configurations. Only god really knows wtf is going on...and he won't tell
Spoke too soon. Fixing the embed like that breaks the social login for OpenID & Google, as the pop-ups start trying to redirect to the new address before authenticating.
@adamoxford said:
Spoke too soon. Fixing the embed like that breaks the social login for OpenID & Google, as the pop-ups start trying to redirect to the new address before authenticating.
I knew it was a "less than ideal" idea to do the brute force changing to _self like that , but I didn't know what it would break. thanks for the insights on how it will break things.
do you know what the webroot is returning in the js when you get the problem redirection.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@peregrine said:
do you know what the webroot is returning in the js when you get the problem redirection.
I'll have a look later on today - it's a public holiday today so have a few other things I need to do but will hopefully have time to mess around with it tonight.
do you know what the webroot is returning in the js when you get the problem redirection.
It appears to be the native location - forum.htxt.co.za. I'm currently running the forum without embedding it (and it will probably stay that way) and Google login works fine. If you try to log in using Google from the blog comments, which are embedded, it gets stuck in the redirect loop.
Also, Facebook login isn't working at all, it comes back with the "Invalid redirect_uri: Given URL is not permitted by the application configuration" on both sites (set up to work with the native location.
Comments
caching on browser or server perhaps? some mysteries are better left unsolved.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
or it could be that one or the other must be disabled . If both are enabled it could cause conflicts. it could be all of the above in various configurations. Only god really knows wtf is going on...and he won't tell
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
OK... here's the weird thing. I was having exactly the same issue (see here).
All I did was change the target to self in js/embed_local.js:
if (isHttp && href.substr(0, webroot.length) != webroot) { $(this).attr('target', '_self');And the embed is working fine. (I hope - site is htxt.co.za/forum)
Spoke too soon. Fixing the embed like that breaks the social login for OpenID & Google, as the pop-ups start trying to redirect to the new address before authenticating.
I knew it was a "less than ideal" idea to do the brute force changing to _self like that , but I didn't know what it would break. thanks for the insights on how it will break things.
do you know what the webroot is returning in the js when you get the problem redirection.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@adamoxford I still am using the target to self fix and my social logins stay within the embedded page:
http://www.djangobooks.com/blog
Maybe something else is causing the redirect?
I'll have a look later on today - it's a public holiday today so have a few other things I need to do but will hopefully have time to mess around with it tonight.
I think it might be a permissions thing. When I select Google or OpenID in the Authenticator settings, I just get the spinning wheel working...
So I was going to > @peregrine said:
It appears to be the native location - forum.htxt.co.za. I'm currently running the forum without embedding it (and it will probably stay that way) and Google login works fine. If you try to log in using Google from the blog comments, which are embedded, it gets stuck in the redirect loop.
Also, Facebook login isn't working at all, it comes back with the "Invalid redirect_uri: Given URL is not permitted by the application configuration" on both sites (set up to work with the native location.