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 <adr...@nexudus.com > <javascript:>> 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 <adr...@nexudus.com> >>> 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, <sarahatwo...@gmail.com> 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 coworking+...@googlegroups.com. >>>>>> 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 coworking+...@googlegroups.com. >>>> 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 coworking+...@googlegroups.com <javascript:>. >> 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 coworking+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
