Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Facebook Login from internal site

Options
  • 27-03-2014 3:07pm
    #1
    azzeretti
    Registered Users Posts: 1,477 ✭✭✭


    I have developed a wireless captive portal (type thingy) for a custoer who required authentication against a custom auth server. Now, after all that, he would like to enable users to authenticate using their Facebook login.

    The trouble is, Facebook Login calls for an app redirect to the actual Facebook site for authentication (it then sends a callback to the redirected page). However, as this is a captive portal all traffic is redirected to the login page until authenticated. If I allowed traffic to Facebook for the auth request it would be open for everyone. That is, it wouldn't take long for the users to realise Facebook is open without authenticating.

    So, does anyone know if there is a way to use Facebook login from a local box and have the Login occur server side, without letting the client go to Facbook!?


Comments

  • Options
    #2
    oscarBravo
    Technology & Internet Moderators Posts: 28,799 Mod ✭✭✭✭oscarBravo


    I think there are only a handful of URLs involved in Facebook's OAuth implementation (I looked into it recently for my own purposes). If you can allow those fairly specific URLs through the captive portal, you should be fine.


  • Options
    #3
    azzeretti
    Registered Users Posts: 1,477 ✭✭✭azzeretti


    oscarBravo wrote: »
    I think there are only a handful of URLs involved in Facebook's OAuth implementation (I looked into it recently for my own purposes). If you can allow those fairly specific URLs through the captive portal, you should be fine.

    There seems to be just one URL https://www.facebook.com/dialog/oauth?client_id=?????
    However, I can't open this up (without some ridiculous iptables regex going on) as it would allow access to the facebook.com too.


  • Options
    #4
    oscarBravo
    Technology & Internet Moderators Posts: 28,799 Mod ✭✭✭✭oscarBravo


    azzeretti wrote: »
    There seems to be just one URL https://www.facebook.com/dialog/oauth?client_id=?????
    However, I can't open this up (without some ridiculous iptables regex going on) as it would allow access to the facebook.com too.

    Hmm, I didn't realise your CP worked at the IP level. I can't really see a way around it, tbh: in order to work server-side, your application would have to ask the user for their Facebook credentials, and the whole point of OAuth is that nobody gets to see those except Facebook and the user.


  • Options
    #5
    Sparks
    Registered Users Posts: 40,038 ✭✭✭✭Sparks


    You could always just write a radius plugin that does the authentication (hell, it's been done before). FreeRadius, if that's what you're using, isn't too hard to write plugins for.


  • Options
    #6
    azzeretti
    Registered Users Posts: 1,477 ✭✭✭azzeretti


    Sparks wrote: »
    You could always just write a radius plugin that does the authentication (hell, it's been done before). FreeRadius, if that's what you're using, isn't too hard to write plugins for.

    Nah, unfortunatley Radius would be too easy for this customer!


  • Advertisement
  • Options
    #7
    azzeretti
    Registered Users Posts: 1,477 ✭✭✭azzeretti


    oscarBravo wrote: »
    Hmm, I didn't realise your CP worked at the IP level. I can't really see a way around it, tbh: in order to work server-side, your application would have to ask the user for their Facebook credentials, and the whole point of OAuth is that nobody gets to see those except Facebook and the user.

    Yep. You'd think this would be pretty common though, enough to have the Facebook login service on hosted elsewhere so as not to open up the whole (sub)domain.


Advertisement