Messages

1

Development and Code Review / Re: CaptivePortal SMS self-registration

« on: October 08, 2018, 11:40:42 pm »

Hey,

Can anyone point me at a better place/forum to have this discussion ?

I'm willing to move forward and just would like to "start right", from a design point of view.

Patrick

2

Development and Code Review / CaptivePortal SMS self-registration

« on: September 21, 2018, 05:55:17 pm »

Dear community, (first-time posting, please be gentle)

I would like to implement self-registration via SMS for the Captive Portal. I searched around and I have found those discussions which lead to no solution so far:

https://forum.opnsense.org/index.php?topic=9148.msg41040#msg41040
https://github.com/opnsense/core/pull/1882

The second link also points to configd overlays, which I think might not be sufficient for this scenario (https://github.com/opnsense/core/issues/1934).

What I have in mind is the following:
1) User gets intercepted and redirected to the Captive Portal
2) User enters his mobile phone number in a form and submits it
3) User gets a "password" via SMS
4) User logs in using his phone number (pre-filled from step #2) and SMS "password"

Now, the way I understand the Captive Portal infrastructure, lighttpd offers a proxy to AccessController.php (bypassing authentication) on port 8999 (reachable via /api/captiveportal/access/). This comes from this line:

https://github.com/opnsense/core/blob/5d2ff1def1c0d4e6e583b1e175785d8a0482dcce/src/opnsense/service/templates/OPNsense/Captiveportal/lighttpd-zone.conf#L104

Looking at the steps, I see step #2 as a "preparation" step that should provision the user on the server-side in order to validate authentication during step #4.

This "preparation" step should be an additional public method in AccessController.php, which is called by the HTML template in order to send out the SMS and "pre-provision" the user "somewhere" for step #4.

"somewhere" could be a text or sqlite database linked to the captive portal or it could be a new proper authentication backend, dedicated to this use-case. What is special about this backend is that users would be short-lived and the backend should be "cleaned" regularly.

With a proper auth backend, step #4 is just a regular login where username/password is replaced by phone_number/sms.

Can anyone let me know if this would be a proper way to get this working or if something better/simpler could work ?

I'm obviously interested in the backend working first, with some hard-coded SMS gateway credentials in the AccessController. The natural next step will be to expose those settings via the frontend config UI and configd.

Thx!