[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Captive-portals] captive portal browser capabilities



I find myself setting up a container that will be deployed as part
of an IoT solution.  It will need to deal with captive portal interfaces
as the purpose of the container is to provide uplink connectivity.

It would be nice if it could be lynx/elinks/etc, but I doubt that
will work well enough.   Running something via ssh-forwarded-X11 would
be acceptable. Ideally the browser is so limited in functionality
that it seldom needs upgrades, and also ideally it's a single (if big) binary
without any LD_PATH dependancies.  And available for armhf :-)

I will not be surprised if there is nothing that satisfies my needs
and is still capable of dealing with portals.

So it occurs to me that maybe a document that establishes a reasonable
subset of capabilities would be a good thing to have.  Then at least,
both portal makers and captive portal browser providers could have
something to work towards.

Maybe this is really W3C work?

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature