|
Hi all, I just wanted to put this out, the (possibly wild) idea is to use the webpush protocol as the mechanism/tunnel by which a captive portal environment (NAS) can send messages to the client. Webpush is pretty
well supported in most browsers and mobile platforms. The (very rough) idea would be that 1.
the RFC7710 URI would point to a document that the client can GET upon receipt 2.
one of the things the document would contain would be a webpush subscription resource 3.
the client would use that to create a push subscription (in this case the push server to use would essentially be chosen by the portal operator but we can likely change that) 4.
the client can either provide the push uri to a specific location (identified in step 2) for sending push messages or the push uri could already have been generated by the captive portal prior to
step 1 5.
whenever the portal/NAS wants the client to interact in some way (indicate captivity, require creds, require payment, time expiring etc), it can send a push message to the client. This would actually
work even in cases where the client may be in sleep mode since the push message would be delivered to the client when it wakes up to retrieve it. 6.
The actual details in the push message could be either a URL to a web page that gets launched in a browser or a JSON payload that the client would consume to interact (in case of constrained clients) The pros are that we leverage an existing mechanism that is already well supported (and continues to improve moving forward) and the messaging itself would be quite flexible. We also restrict the role of the
API Server to be nothing more than a forwarder between the NAS/CP and the client. David has mentioned in the other discussions that he prefers the NAS to be the “source of truth” and with webpush, the NAS can pretty much control what messages it “pushes” to
the client. I’m still thinking thru if this would be work “in addition” to a basic ICMP message or if we can avoid using ICMP altogether in certain cases.
Darshak |