Third party Register via Facebook broke in canvas..

[Mike Edge]

Trying to login or create an account inside of Facebook canvas broke again in upgrading to 1.4.4. Returning back to site produces a white page with no further errors. This worked with 1.4.3 and $config['enableClickjackingProtection'] = false; is already added to config.php

 

[Chris D]

We've not explicitly made any changes there.

Do you have a way of testing this on a different set up?

White pages are usually suppressed server errors. If you add to config.php:

ini_set('display_errors', true);

And try again do you get any more info?

 

[Mike Edge]

Still just a blank page, same with viewing source. Oddly I found if you right click the login with facebook and open in new tab it opens the page to create an account. Can I PM you my canvas URL @Chris D to take a closer look?

 

[Mike Edge]

Using now as a temp fix

  <li><a href="{xen:link register/facebook, '', 'reg=1'}" class="fbLogin" tabindex="110" target="_blank"><span>{xen:phrase login_with_facebook}</span></a></li>

Though foricing a new tab on someone is a bit intrusive imo.. So hopefully we can get this resolved soon.

 

[Chris D]

Still just a blank page, same with viewing source. Oddly I found if you right click the login with facebook and open in new tab it opens the page to create an account. Can I PM you my canvas URL @Chris D to take a closer look?

Yes, PM away, I'll take a look.

 

[Chris D]

This is logged in the browser console:

Refused to display 'https://www.facebook.com/dialog/oauth?client_id=123&scope=publi…123&redirect_uri=<YOUR URL>' in a frame because it set 'X-Frame-Options' to 'DENY'.

(I have redacted any potentially private identifiers).

I don't get any sort of blank page, though.

 

[Mike Edge]

This is logged in the browser console:

Refused to display 'https://www.facebook.com/dialog/oauth?client_id=123&scope=publi…123&redirect_uri=<YOUR URL>' in a frame because it set 'X-Frame-Options' to 'DENY'.

(I have redacted any potentially private identifiers).

I don't get any sort of blank page, though.

hmmm I have $config['enableClickjackingProtection'] = false; so wonder why it is setting to deny and more so, why this changed in 1.4.4

 

[Chris D]

It hasn't changed in XF 1.4.4 (from a code perspective).

We don't actually set DENY as a value anywhere. DENY is coming from your server somewhere (or certainly not from XF at least).

Could you remove the clickjackprotection line from your config.php and let me have another look?

 

[Mike Edge]

ok removed

 

[Mike]

Unfortunately, the page being loaded into the iframe is a Facebook page and Facebook is sending the header. The only way to workaround this would be to break out of the iframe. There's nothing that we can do at this time (changing the FB integration approach may solve it but that's not a feasible change currently).

 

[Chris D]

I see, that's what causes the page to go white, then.

Yeah the DENY thing isn't coming from XF.

If you look at the previous error, and compare it to this one now that click jacking is enabled:

 Refused to display 'https://YOUR-URL.com/' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

The previous message, it's actually a Facebook URL which is sending the DENY header. As you'll see from the most recent error, now clickjack protection is re-enabled, it's your URL that is sending a header (the correct one for clickjack protection being enabled).

So doing a little bit more digging, actually, Facebook have changed something so that the oauth dialog cannot be opened within an iframe. Therefore, at the moment, opening it in a new tab is all FB will allow you to do.

 

[Mike Edge]

Unfortunately, the page being loaded into the iframe is a Facebook page and Facebook is sending the header. The only way to workaround this would be to break out of the iframe. There's nothing that we can do at this time (changing the FB integration approach may solve it but that's not a feasible change currently).

so opening in a new tab is about the only feasible solution at this point @Mike ?

 

[Mike Edge]

I see, that's what causes the page to go white, then.

Yeah the DENY thing isn't coming from XF.

If you look at the previous error, and compare it to this one now that click jacking is enabled:

 Refused to display 'https://YOUR-URL.com/' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

The previous message, it's actually a Facebook URL which is sending the DENY header. As you'll see from the most recent error, now clickjack protection is re-enabled, it's your URL that is sending a header (the correct one for clickjack protection being enabled).

So doing a little bit more digging, actually, Facebook have changed something so that the oauth dialog cannot be opened within an iframe. Therefore, at the moment, opening it in a new tab is all FB will allow you to do.

Thanks Chris, I wonder if it's new for prep of the new oAuth coming out.