Neat, thanks Adrian! Curious - do you know if it's possible to only do that authentication once? Essentially, once a device's mac is registered, can the hotspot portal let people connect without additional logins in the future, so long as the device is known?
------------------ *The #1 mistake in community building is doing it by yourself.* Better Coworkers: http://indyhall.org Weekly Coworking Tips: http://coworkingweekly.com My Audiobook: https://theindyhallway.com/ten On Tue, Apr 18, 2017 at 4:09 PM, Adrian Palacios <[email protected]> wrote: > Right! You somehow need to make that link between mac and member :). With > UniFi, the simplest option is to enable the hotspot portal and redirect the > authentication page to a server of your own. UniFi will send your server > the MAC address of the member trying to authenticate and a few variables to > let your server make sure the call is legit. You would then ask the user > for their credentials (email, password,...?) and validate them against your > member database. If valid, you would store the mac with the user in your > database (that's the link between a user and the mac!) and send the user > back to the UniFI controller letting it know the authentication was OK so > they can connect to network, again with some magic to let Unifi your call > is legit too. > > Attached an example of what your own sever would look like to get you > going! Can't find right now where I got it from but it helped us crack this > process. > > On Tuesday, April 18, 2017 at 8:45:07 PM UTC+1, Alex Hillman wrote: >> >> Adrian - yep, we've worked pretty extensively with the API, but that >> doesn't *really* help tie a specific device's MAC address to it's >> owners' account. Pretty sure that's where something like a captive portal >> is needed, right? >> >> >> ------------------ >> *The #1 mistake in community building is doing it by yourself.* >> Better Coworkers: http://indyhall.org >> Weekly Coworking Tips: http://coworkingweekly.com >> My Audiobook: https://theindyhallway.com/ten >> >> On Tue, Apr 18, 2017 at 3:42 PM, Adrian Palacios <[email protected]> >> wrote: >> >>> @Alex, slight side-answer. Unify controllers have a great API that >>> exposes every imaginable piece of data about connected clients and your >>> network. Docs from Ubiquiti are pretty poor but this project >>> <https://github.com/malle-pietje/Unifi-API-browser.> and its source >>> provides a quick way to get started accessing that data >>> https://github.com/malle-pietje/Unifi-API-browser. A small service >>> reading event data or connected clients every a few minutes can easily be >>> used to check members in and out. >>> >>> @Jacob Jay. We currently connect to a range of hotspot/captive portal >>> devices, some of them incredibly capable. My personal favourite? Mikrotik. >>> They are the underdog out of all of the ones we connect to but they have >>> nothing to envy to the big boys. We have seen plenty of success cases and >>> networks with over 2K devices, or more during events, running just fine + >>> the play nice with Uniquity APs, which I think are unbeatable. Members only >>> need to check in the first time they use a new device, we will remember >>> them from that moment on. Unlike many of the ones we've worked with, their >>> built-in scripting engine and events system makes it really easy to build >>> integrations with other systems without having to rely on the infamous >>> RADIUS! >>> >>> @Steve Suard. If you plan to build your own RFID tool, this reader >>> <https://www.d-logic.net/nfc-rfid-reader-sdk/products/ufr-classic> is >>> pretty reliable and comes with SDKs for a good number of programming >>> languages. Building a tool that reads a card and compares that to a local >>> database should not be too difficult, if you have access to a coder. That >>> ugly thing is the most reliable we've found out of the ones we have tested. >>> >>> @Sarah. There are plenty of options to facilitate check-ins when using >>> NX (front-desk ipads, desktop readers, door readers/access control, >>> wifi/network tracking, ...). A bit depends on budget, feel free to reach >>> out to discuss. This will also give you the basic options without going >>> into too much technical detail: http://www.nexudus.com >>> /en/blog/read/292950659/the-art-of-checking-members-in-and-out >>> >>> Adrian >>> >>> >>> >>> >>> >>> On Tuesday, April 18, 2017 at 7:24:31 PM UTC+1, Alex Hillman wrote: >>>> >>>> Slight side-consideration, but I'd be curious of accounts from anybody >>>> using *network access* to assist with check-ins/attendance? >>>> >>>> We have are using Unifi for our network management and the latest >>>> versions have a rather robust captive portal (sign in to get online) setup, >>>> but I haven't had a chance to play with it yet. Has anyone else? >>>> >>>> -Alex >>>> >>>> >>>> ------------------ >>>> *The #1 mistake in community building is doing it by yourself.* >>>> Better Coworkers: http://indyhall.org >>>> Weekly Coworking Tips: http://coworkingweekly.com >>>> My Audiobook: https://theindyhallway.com/ten >>>> >>>> On Tue, Apr 18, 2017 at 2:18 PM, <[email protected]> wrote: >>>> >>>>> Ha, well, @Jacob J thanks for the vote of confidence, but I still only >>>>> followed half of what you wrote in your most recent reply. >>>>> >>>>> We are quite low tech at the moment - handling our check-ins manually >>>>> (yup, that's me, sitting at reception). I do like the daily fac-to-face >>>>> with the members. >>>>> >>>>> I think that for now, getting the access issues at our second location >>>>> is the most critical. >>>>> >>>>> Glad to hear Nexudus is so flexible. Will speak to them about options >>>>> for automating the check-ins. >>>>> >>>>> As I learn more about all of the possible ways to automate, I know >>>>> I'll come back to your post as it's full of good info. >>>>> >>>>> Much appreciated! >>>>> >>>>> >>>>> On Tuesday, April 18, 2017 at 11:09:29 AM UTC-4, Jacob Jay wrote: >>>>>> >>>>>> Pretty much bang on, you've enough technical chops to distill the >>>>>> jargon ;) >>>>>> >>>>>> 1. Yes. If a standalone script, you would have to maintain a separate >>>>>> list of IDs/names/expiries. (Inadvisable and extra work alongside a >>>>>> management app, but if one only has DIY offline management processes not >>>>>> so >>>>>> much an issue.) >>>>>> >>>>>> 2. Yes. You can use an input/trigger such as an RFID swipe to do >>>>>> anything you want -- the output/action, in your case unlock a door (and >>>>>> maybe checkin). If we got fancier still you could turn the lights on, >>>>>> start >>>>>> a coffee brewing etc ;) >>>>>> >>>>>> I like and do agree with what Sayles says on the human interaction >>>>>> element however not all spaces have a full-time manager, nor necessarily >>>>>> at >>>>>> the door, and thus tech-driven solutions are needed. >>>>>> >>>>>> 3. Yep. Darned humans, they can be too polite and don't know how to >>>>>> keep their variables within a system's process bounds. 🤷♂️🙃 >>>>>> >>>>>> I would always advise making allowances for this, whether technically >>>>>> or with backup/primary manager-driven interactions. Anything that >>>>>> introduces potential frustration to a user is obviously a bad thing. I >>>>>> think WiFi as a primary checkin system is better than RFID, but with RFID >>>>>> for access control. WiFi can actually check people in even as their phone >>>>>> approaches the main door. >>>>>> >>>>>> If you need, and how you implement such tech approaches is also down >>>>>> to size, smaller spaces probably don't need either if they're staffed >>>>>> because you know who's-who and can address them directly about >>>>>> renewals/usage. Large spaces really need both especially if managers are >>>>>> not always present. If you're mid-sized both could be nice and I >>>>>> understand >>>>>> given the apparent complexity why spaces haven't used both, but it's not >>>>>> unduly hard if you've got someone who can help. However no management app >>>>>> has the complexities figured out to result in a simple user experience in >>>>>> all scenarios. This is where the best practices/advice for models and >>>>>> approaches from other's here can be help, such as Sayles' recommendation >>>>>> for direct interaction, assuming they align with one's own resources. >>>>>> >>>>>> If access control is a priority then you can forget the WiFi. Whereas >>>>>> if you have hourly billing or a usage-based plan then WiFi is really >>>>>> required for accurate billing if the access control is loose ('door >>>>>> holding'). >>>>>> >>>>>> Nexudus' own WiFi checkin involves installing a special router, which >>>>>> for two reasons I don't like: 1. it's not a particularly powerful one >>>>>> (although I haven't checked the latest models but I doubt they're as good >>>>>> as dedicated WiFi/routers which is after all at the crux of a space's >>>>>> service), 2. I despair at any system that requires users to login using a >>>>>> webpage especially when carrying multiple devices, let alone keep a >>>>>> browser >>>>>> window open. For ease of use WiFi should simply be password-protected and >>>>>> that's that. >>>>>> >>>>>> I implemented for myself an essentially opt-in simple WiFi script as >>>>>> a primary checkin system that only requires a user to signin a single >>>>>> time >>>>>> for at least their primary device. This approach could however be made to >>>>>> require users to signin every new device. Maybe the management app devs >>>>>> will improve their systems in time… otherwise we have to hack together >>>>>> our >>>>>> own solutions using their APIs if we want better WiFi checkin. >>>>>> >>>>>> 4. This is down to the specific implementation of a RFID >>>>>> script/program, personally I'd make it part-and-parcel to sync with a >>>>>> hosted app so that if the net is temporarily down it keeps the last valid >>>>>> membership state for each user to always let them in, and also the last >>>>>> swipe times to sync as checkins with the app. >>>>>> >>>>>> An "API" (Application Programming Interface) is a set of functions >>>>>> that one application can use to talk to another, e.g. a local >>>>>> script/program to a hosted management app. If the management app has a >>>>>> suitable function you can invoke that function to get/set stuff. The >>>>>> Nexudus API is quite comprehensive, and allows you to manage RFIDs, >>>>>> users, >>>>>> checkins and apparently WiFi devices too so strictly speaking anything >>>>>> you >>>>>> want to do could be integrated, and thus it appears one doesn't in fact >>>>>> have to use the Nexudus WiFi checkin system but use one's own. >>>>>> >>>>>> Such a script/program has to be always running watching for swipes, >>>>>> and whenever one occurs, attempt to connect to the management app API to >>>>>> validate/checkin the corresponding user. I've used these separate terms >>>>>> to >>>>>> differentiate between the locally-running script/program (on a controller >>>>>> board/PC) and remote hosted management app (on the cloud) but technically >>>>>> they can all be considered as 'apps'. >>>>>> >>>>>> @Sayles offline sync is what you've already done for your own system? >>>>>> What was the issue with the Pi? >>>>>> >>>>>> Sarah, there's a pile of such controller boards and they're not all >>>>>> compatible so when having a program written to do this, one has to make >>>>>> sure the hardware device ('board') is appropriate. There are however some >>>>>> that make it super simple and you can download apps from the 'cloud' to >>>>>> it >>>>>> with a click. So imagine if you simply ordered this controller board, >>>>>> plugged it in, had an electrician connect a wire between it and your door >>>>>> lock and another to the RFID reader, then that I said all you have to do >>>>>> is >>>>>> go to a webpage to enable the app/script on it. Obviously said app needs >>>>>> to >>>>>> be written though… >>>>>> >>>>>> *But* I haven't investigated the security implications of this cloud >>>>>> system and indeed I wouldn't want such a board directly exposed to the >>>>>> net >>>>>> anyway. Your insurers might'nt be too happy, although I'd be quite >>>>>> surprised if they'd have clauses about such things yet…? Otherwise you'd >>>>>> need a local hacker who can write/install the script/program directly on >>>>>> any controller board (e.g. RaspberryPi, BeagleBone, Arduino, …). >>>>>> >>>>>> HTH. >>>>>> >>>>>> >>>>>> -- >>>>> Visit this forum on the web at http://discuss.coworking.com >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Coworking" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> Visit this forum on the web at http://discuss.coworking.com >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Coworking" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > Visit this forum on the web at http://discuss.coworking.com > --- > You received this message because you are subscribed to the Google Groups > "Coworking" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Visit this forum on the web at http://discuss.coworking.com --- You received this message because you are subscribed to the Google Groups "Coworking" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
