RadiusDesk & Login with Facebook....
The professional way to manage your WiFi network using FreeRADIUS
Brought to you by:
dvdwalt
Menu
▾
▴
Hi Mate
Is possible create the "Button" Login with Facebook on RadiusDesk ?
Link application Facebook:
- https://developers.facebook.com/docs/facebook-login
Help !!!
Update RadiusDesk, now also other software Radius, have "Login With Facebook or Login with Twitter"...the worl connect with social wifi.
Hi Bruno,
Yes this is in the pipeline for the future. At the moment we are looking at ways how to get funding to implement this is a proper and efficient way.
This means that we will need a substantial amount of money to help me dedicate at least four months of my time to complete this.
Kind regards
facebook login itself should be fast to implement.
the problem which others softwares have is to walled garden all facebook domain to feature this possibility and sadly mobile FB App are working without any authentication in captive portal. not a good thing.
facebook integration in radiudesk can be used to self register users getting fb public information like Firstname, secondname, email and phone number.
facebook can be very effective also to advertise activities by forcing "Like some page" (per dynamic login page basis).
maybe the faster integration with rd should be to bound a fb profile like a sort of mac-address in click-to-connect ..
my 2 cents
Hi Bruno,
The coding for Facebook (and many other Social Networks) integration started.
I will however first have to launch a serious funding campaign in order that the time I spent to complete this is not out of may own pocket.
So far the initial test seems positive and doable probably on both CoovaChilli and Mikrotik.
http://www.radiusdesk.com/developers_corner/facebook_overview
I assume this makes sense :-)
Kind regards
Hi Dirk
i read the fb overview, in the way you described the authentication process, you use a temp Radiusdesk account to be able to connect to facebook login ?
If yes, in this time span, the end user is already logged in and thus can connects everywhere ?
Hi Fabrizio,
Yes, we'll probably keep the session time for that account small like under two minutes and throttle the bandwidth so it will be actually not of much use beyond useful to authenticate using one of the OAuth providers.
So if a person want to misuse that account he will be a on the short end with limited bandwidth and having to reconnect every two minutes for another two minutes.
This however seems to be the simplest option which can be used with the least disruption in the most places.
This open a sort of "self care" section on Radiusdesk.
a section in which the user can register itself by using the "SELF Access Provider" selecting the available profile(if multiple).
Here the user is asking to type general data or by using social account to fillup fields. maybe in future can be implemented a sort of verification by sms/call.
This is only a my hypothesis
Just a question:
can the Oauth process be proxied ?
in this way we can allow walled garden for the proxy only.
Hi Guys,
I thought I'd jump in on this and provide some input from our experiences of running social login with Radiusdesk for over a year now. We started out as Dirk has described by being concerned about the social sites being open if allowed in the walled garden.
We took the same approach and setup a page that would effectively log them in in the background with a short voucher timeout. Effectively transparent to the user who wasn't aware they were actually logged in to the hotspot. We ran with this for a while, but encountered continued issues from users who would not complete the login process quick enough.
At the point we opted to ditch the approach and just have facebook open in walled garden we had the temporary background login running at 10 minutes and we were still having issues with users. At that point we took a step back and looked at the big players in the market, PurpleWifi, Cloud4wi etc. They all just allow the social sites they have logins for in the walled garden.
Why do they do this? We figured because it's much easier to do, the user experience is much better and the cost of maintaining a method that prevents it (such as described above) far out weighs the cost from the small amount of people who would workout they can access facebook without logging in and actually do that.
Since we moved away from a temporary voucher to provide access to social login, we have been headache free.
A quick note on implementing social login as well. Again we took the approach of building our own facebook login integration on our own custom captive portal page. This has served us well to a degree and we built our own database tables to store profile information etc. However, maintaining even just the facebook login has been a task in itself given the frequency the API changes, not to mention the facebook login process can have different issues on different devices and finding the resources to continually test and even debug issues on every new phone that comes out is endless. Add to this we then want google+, twitter, linkedIN etc etc. Suddenly you have a mammoth, costly task on your hands to maintain social login integration, let alone code to store and analyse the different profile data.
Also there's a few gotchas to watch out for regarding the login process particularly on iOS devices. If you have your hotspot configured to popup the captive portal window on iOS devices on detection of a hotspot (ie you haven't allowed the sites apple check to determine if they have internet access in your walled garden). You'll hit some issues trying to invoke the facebook login page from the SDK. Safari on iOS blocks this request as it thinks it's a popup. You need to actually build the login url and redirect the client to the url.
We decided to move to a 3rd party social login integration for our next iteration. I realise it's not completely open source, but I'm a firm believer in leverage. Sometimes using a service that has total focus on the thing you need can be the most sensible decision. Let them do what they do best while we concentrate on what we do. Radius desk is about wifi management, I think diverting focus from that to get in to the very in-depth and messy world of social login integration might not be the best use of resources. That is of course just my opinion on my own experience in the area.
A service like http://janrain.com/ could be a much better approach in the long run and much quicker to get up and running and provide not just facebook, but any type of social login. It is free for the first 2500 users per year. You could even setup a free account per location if you really wanted to. They also have a rich API that could be easily integrated to pull data in to radius desk if needed.
I'll leave the thought there, I've definitely typed too much for one post already. Hopefully it's of some value. Please feel free to comment or ask questions. Happy to provide all the input I can to help.
Cheers
Paul
Last edit: fridaystreet 2015-03-23
Hi Paul,
Thanks for sharing your experience. This surely will help pinpoint problems more easy when people implement the current FB integration offering in SVN.
I agree with you on having a sort of generic approach. For this reason I've chosen the most active Open Source provider at the moment called Opauth (http://opauth.org/)
I trust that there are already enough people implementing the more popular Strategies that in Opauth there will be fixes coming at a timely interval if something changes in the API.
Other people I spoke with also shared your same experience in terms of always having to fix things up when the API changes up to the point where they eventually give up.
This then makes sense then that there will be third party providers which one can pay to fix things up for you.
Perhaps another approach for the temporary user is to give it very little bandwidth instead of a 10 minute timeout... just enough for the FB login page but not enough to browse comfortably ....
Kind regards
Hi Dirk,
Good to hear from you again, I hope you're well. It's been a while since I've had a chance to jump on the forum and provide some input. Apologies I didn't realise you had picked a 3rd party framework. I think Opauth is a good choice as well for doing things internally. We just wanted to farm out all of the data storage and analysis as well, plus we do posts out to peoples news feeds when they login. Otherwise I probably would have used it too I think.
If I get some decent Janrain stuff up and running I'll submit it and you can have a look and decide if it's worth providing it as a secondary option as well.
Regarding the bandwidth, our experience over the last 18 months has been that the login process to the hotspot needs as much bandwidth as you can give it and needs to be as fast as possible to keep the user experience at an acceptable level. We done a few focus groups with some of our clients customers and the time to login was one of the biggest gripes. We used to limit the bandwidth for browsing once connected to 1mbs. With the social login we ended up removing the limit completely. Some devices are just slow to open the facebook redirect popups no matter how much bandwidth you give them.
If you take in to account the fact that most people use the facebook app now and so are not actually logged in to facebook in the browser they need to login to fb as well (this was about 90% of our test subjects), the login process you have is.
There's is a lot going on there. Our customers feedback has shown us that limiting bandwidth during this process created a bit of frustration and at times on older devices the process stalled completely. Or because the facebook login page would take so long to appear to do anything, the user would just click off the page thinking something was wrong. This would mean they would try and load the page again and go back to the portal login page and the cycle continued. We were actually completely surprised at how impatient end users were. From those findings we went to the trouble of putting a message up before the redirect saying "please be patient" :-) hahaha
Maybe make it optional to use the temp login or just have it open via the walled garden. That way if a particular location is suffering the same sort of issues we found, they can just use the walled garden instead.
Cheers
Paul
This topic has become very interesting.
i had in fact some issue with cloud4wi because the login process is endless, too slow for most hurried people.
one problem is timeout of android login(in case of popup hotspot detection) causing wireless disconnection thus breaking the process of authentication.
second: if we walled garden facebook, the android/ios FB APP almost saturates the bandwidth in background. Same thing appears for google+/android services, even faster.
So in previous post i've advised to proxy the process in a way the NAS/Captive portal gateway have to walled garden the proxy only.
I have not not understood if this can be doable.
Cheers
Hi Fabrizio,
As far as I know it's not possible to proxy an oauth login
programmatically. I looked in to this as well for the very same reason.
Unless you mean to use a proxy server, but in that case you're in the same
position you started. Maybe by some possibility you could use some sort of
in-browser proxy, sort of like a remote browser in a browser? Not sure if
that even exists, but even if it does it's starting to look a little bit
dodgy and your credibility and user confidence that you're not going to do
something dodgy with their data or be phishing goes down the tube.
One of the key points of oauth as I understand it is to ensure the person
logging in is the actual account holder and it is an actual real human
instigated login attempt and not an automated one. Being forced to be
redirected to the social provider's actual page to login means they can
setup local sessions on the client and have control over that process. This
also protects against phishing.
To this end I would even go as far as to say I would imagine there is
something in the Facebook terms and conditions stating if it can be
circumvented somehow then it would be against their security policy, so you
couldn't legitimately do it anyway. I think from memory there is actually
something to the effect of not logging in on behalf of a user.
Just on that point, I was surprised to find that Facebook policies actually
restrict you from forcing someone to like your page in return for something
else (eg access to a site or a product). So just a note to anyone on here
to be careful how you set that up. The way we have gotten around it is to
ensure there is always a secondary method of access to choose, just leave
us your email instead. We find lots of people still use Facebook though.
I'm not sure if a payment method as the secondary would even be valid
either. From how it reads it sounds as though the user should be able to
access the content or service if they wanted to like the page or not. So
any secondary method would need to be if equivalent cost, ie free. That
could be wrong though, that's just my interpretation.
Anyway just a few points to keep in mind. The fb terms are an eye opener if
anyone is thinking of utilising fb in their software I'd highly recommend
reading them first
Cheers
Paul
On 23/03/2015 6:24 PM, "Fabrizio Lazzaretti" fabsoft@users.sf.net wrote:
OK,
Managed to complete the documentation if you'd like to give the latest SVN a spin.
http://www.radiusdesk.com/user_guide/social_login
Just need to complete the part where we store the data obtained from the provider
I also came across the FB policy where they changed it to No more bribes for Likes....
Cheers
Great works !
I will happy to try out the code next week.
I actually have the lastest VM image (2015-2-0) installed on virtualbox,
can i update that distro by following this guide ?
http://www.radiusdesk.com/getting_started/update_ubuntu_nginx
Thanks
Last edit: Rafael Marconi 2015-05-08
Last edit: Rafael Marconi 2015-05-08
hi guys anybody tested fb login.
Need help to with fb login
Hi Sameer,
I am currently in contact with Dirk to get this in order.
We are setting up a demo environment and are conducting some tests to find the bug that is blocking this feature.
Follow my thread ( https://sourceforge.net/p/radiusdesk/discussion/help/thread/37b3cee5/ ) for updates on this matter.
Dirk told me he is very busy at the moment, but as soon as we get the demo environment going we will have progress soon.
Best regards,
Steven Kusters
President & Co-founder at Suited Coders
https://suitedcoders.com