Awesome. Great to know. Thanks Adrian!
------------------ *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:18 PM, Adrian Palacios <[email protected]> wrote: > Sure! that's easy too. When a known client connects to your network, UniFi > will send that user to your custom portal with their mac address, as per my > last message, nothing new here. When you receive that mac address, look the > user up by mac address in your database, if you find it, before asking them > to log in, just send them back to UniFi as if they logged in using a > username/password to let UniFI know they are good to go. > > On Tuesday, April 18, 2017 at 9:12:54 PM UTC+1, Alex Hillman wrote: >> >> 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. > -- 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.
