@sratakhin wrote:
I was pretty excited about this feature... until I tried to make it work. I tested it on my Ubiquiti controller with the latest update and firmware on the AP... it sort of works, the guests are asked to check in for free WiFi. However
1. It opens the browser by default and who browses Facebook with their browser?
2. Users can ignore the pop-up window, and not do check-in or enter the access code. Guess what, their computer/phone will indicate limited WiFi connectivity but it works fine! I was able to watch Youtube, check my emails, go to bank apps, chat on Messenger - all without having to check in. This makes the feature useless.
@sratakhin Unfortunately this appears to be a Facebook requirement that UBNT have to follow to get their implementation approved. No way around it if you want to use Facebook WiFi. Otherwise, I suggest you use the plain Facebook auth option.
@klinders5 I can confirm that is how Facebook requires Facebook Wi-Fi to function- they require passing of https traffic prior to authorization. So you will notice if you try to access any http site prior to going through the guest portal you will be unable to do so. Same requirement from FB applies to other vendors on that list.
I can see why it's not ideal for some applications given that is how it works but I think it is still a useful feature for a number of cases.
Ubiquiti Networks Enterprise Support Team
Check out our ever-evolving Help Center for answers to many common questions!
Here are some similar reports with other platforms:
https://www.facebook.com/business/help/community/question/?id=10153805096027169
OK,
I've tried with a Meraki MR18 and facebook WiFi.
It shows exactly the same behaviour as with unifi which is CRAZY.
I can netflix, do email and everything before I go to the facebook checkin 
(((
The only thing that doesn't work is http.
I don't understand the idea behind it.
Bummer indeed! Thanks for testing.
Unfortunately, when you try to ask Facebook support you'll see from the link I shared earlier, they don't respond at all to such questions...
@Kris_Verdonck wrote:OK,
I've tried with a Meraki MR18 and facebook WiFi.
It shows exactly the same behaviour as with unifi which is CRAZY.
I can netflix, do email and everything before I go to the facebook checkin
The only thing that doesn't work is http.
I don't understand the idea behind it.
I stand corrected, it does seem this is a crappy limitation of the FB Wifi feature and not a UBNT issue.
Man, thats sad that they did it this way.
using the IP networks provided by Ubiquiti here
https://help.ubnt.com/hc/en-us/articles/115000871247-UniFi-Social-Media-Guest-Authentication
i was able to get a config.properties file for a site, dropping the 'allow all tcp 443 before authentication' rule, and replace for allow tcp/443 for only the IP networks listed on that article.
it worked fine, so i don't have anymore the 'EVERYTHING tcp/443 is allowed'.
However, after that, came the second (and killer problem to me), which renders the Facebook WiFi feature useles ... Apple changed its portal captive detection agent, and the authentication popup DO NOT automatically appears on iOS devices. It appears automatically on Android devices, on all i could test, but do NOT appears on Apple products. If the user opens the browser, tries to browse something non-https, it will readly and with no errors be redirected to the auth page, and the authentication actually works just fine. If it tries https address, or it will not work or it will give certicicate errors if i had choose to redirect HTTPS traffic.
That being said, the Facebook WiFi feature, if not working 'automagically' on iOS devices, is useless to me. It has to be easy, requiring user to manually opens the browser and trying to browser something, is a definitely NO GO for me. And that happens because of the way Apple captive portal agent works, really nothing Ubiquiti/UniFi can do to change a client device behavior.
@klinders5 wrote:I stand corrected, it does seem this is a crappy limitation of the FB Wifi feature and not a UBNT issue.
Man, thats sad that they did it this way.
It's clearly a VERY LAZY requirement for not having them to keep the login pages on designated some IP network (or networks), giving them complete freedom to change anything without having to communicate their partners. They simply requires everything TCP/443 so they can change anything they wont and their login will always keep running, no matter if that will COMPLETLY screw the idea of 'you MUST authenticate first before having internet access'.
@sratakhin wrote:Do the iOS devices showthe captive portals for things like airport WiFi, hotels, and the like?
if the portal captive code do *NOT* requires cookies and some other features commonly present on hotspot systems, than it should work just fine. The major issue on iOS seems to be that the checkin code, which is provided by Facebook servers (nothing Unifi can do to change the HTML code sent) relies on cookies. iOS devices downloads the page but do not shows it because (apparently) detects it uses unsupported features (cookies in this case) on the captive network restricted browser instance.
If your portal code do not have cookies, it should present just fine on iOS devices. Other UniFi options, for instance, presents just fine on iOS devices. Facebook WiFi checkin, whose HTML code is provided directly by Facebook servers, do not shows because (apparently) it uses cookies.