Expose captive portal status
Categories
(WebExtensions :: General, enhancement, P2)
Tracking
(firefox68 fixed)
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: mixedpuppy, Assigned: mixedpuppy)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
We need to possibly handle proxy in some unique fashion when the browser is behind a captive portal. TBD
Probably the best place to expose this is on browserSettings[1], but possibly on proxy.settings.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browserSettings
Comment 1•6 years ago
|
||
Bugbug thinks this bug is a task, but please change it back in case of error.
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
:mconca fyi on new api for secure proxy support. I think this is generically useful for other proxy extensions, probably others, in order to know the captive portal state. I have not required mozillaAddons for this. The API provides current state and event listeners to watch for state changes.
Comment 4•6 years ago
|
||
:mixedpuppy I agree that there are use cases. Any privacy concerns? Does knowing if a user is going through a captive portal indicate they are away (cafe, hotel, etc.) versus on a dedicated home/work network? Does that matter?
Assignee | ||
Comment 5•6 years ago
|
||
:mconca, Apparently you can detect captive portals without this, they already have code for it (this was low priority, but super easy to do). Given that, I don't think we're exposing anything new. So, the point of exposing this is to reduce that duplication in the extension and ensure the behavior is consistent with what Firefox does internally.
Comment 6•6 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #5)
:mconca, Apparently you can detect captive portals without this, they already have code for it (this was low priority, but super easy to do). Given that, I don't think we're exposing anything new. So, the point of exposing this is to reduce that duplication in the extension and ensure the behavior is consistent with what Firefox does internally.
+1 for making this public
Comment 7•6 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #5)
:mconca, Apparently you can detect captive portals without this, they already have code for it (this was low priority, but super easy to do). Given that, I don't think we're exposing anything new. So, the point of exposing this is to reduce that duplication in the extension and ensure the behavior is consistent with what Firefox does internally.
You are right, we do not expose anything new. Our captive portal detection only detects that a captive portal redirects request to a log-in page or an agree-on-term-of-servces page. An extension can detect the same redirect if it sends a request early-enough, before the user enters password, accept the term of service, etc.
Assignee | ||
Comment 8•6 years ago
|
||
Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
bugherder |
Comment 13•5 years ago
|
||
Can you please provide some STR for this issue so we can check it manually? If no manual testing is needed please mark it as "qe-verify- "
Assignee | ||
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Looks like this wasn't documented yet, can we make that happen?
Comment 15•5 years ago
|
||
I would also be interested in seeing this documented on MDN. We want to detect captive portals for some DNS-over-HTTPS related work.
Comment 16•5 years ago
|
||
Could I get some details on what needs to be documented?
Assignee | ||
Comment 17•5 years ago
|
||
Documentation I believe is at least in part generated based on the schema, then further crafted.
The test can sometimes also help in generating any example.
Comment 18•5 years ago
|
||
Review and feedback of draft of the MDN content sought. Thanks!
Comment 19•5 years ago
|
||
In addition to feedback on the API page content, opinions on the need for a web extension example are also sought.
Assignee | ||
Comment 20•5 years ago
|
||
That all seems reasonable. I don't think we need a full example.
Assignee | ||
Updated•2 years ago
|
Description
•