Closed PotatoCider closed 8 months ago
This is what is sorely missing right now. I hope this PR will be merged.
Yes! How much testing have you done?
I'm using this feature currently in a smart door lock, it works well for my use case. So far I've not encountered any bugs other than the captive portal not supporting HTTP auth prompts so a regular web browser would be required to login.
If usecp, and auth for cp, add noauth landing page, pretty sure you cannot do digest auth via a form.. hmm
Add ability for auth to select pages, OTA, ERASE
I don't think this is necessary. This will be confusing. After all, we can dynamically turn authentication on and off in code:
if (wm.getWebPortalActive()) {
wm.setAuthentication(true);
}
// ...
if (wm.getConfigPortalActive()) {
wm.setAuthentication(false);
}
Breaks captive portal detections, how can we add options here, can we omit root perhaps, or add an auth splash page
I see in the library code that the captivePortal() method is called before the handleRequest() method, so this should not affect the operation of the captive portal.
Also, I think captive portal should be disabled for WebPortal because it breaks port forwarding. In my projects I solved it like this:
if (wm.getWebPortalActive()) {
wm.setCaptivePortalEnable(false);
}
That is already another issue, #982
It does break captive portal probes, I tested this, may be solvable with a header or http resp I gave up on this previously #1044, as it also did not work with cp at all on OSX/IOS devices, there is no auth in the cp browser
Good point about cp on webportal, surpised this hasnt been noticed before, how does it break port forwarding, got a test case?
Since AP mode is secure by nature ( assuming its not open! )
Options probably are Only apply to STA+WebPortal Only apply to AP+Webportal ( requires 'in cp' detection ) kind of impractical, but we want to make sure not to break the captiveportal either.
Good point about cp on webportal, surpised this hasnt been noticed before, how does it break port forwarding, got a test case?
You can flash any sketch and try to forward port 8181 -> 80 through the router. This can also be easily checked using the wokwi emulator. I noticed this by chance when one of the users encountered a problem and I asked him to provide access to the ESP. When I opened IP:8181, a redirect (302) to IP:80 occurred. https://github.com/tzapu/WiFiManager/blob/18145e42ba686f297d4e741fb8805dffcb99a920/WiFiManager.cpp#L2451
Since AP mode is secure by nature ( assuming its not open! )
Options probably are Only apply to STA+WebPortal Only apply to AP+Webportal ( requires 'in cp' detection ) kind of impractical, but we want to make sure not to break the captiveportal either.
In my projects, the web portal always works (only if the ESP is connected to Wi-Fi), since some settings are made through it.
I gave up on this previously #1044, as it also did not work with cp at all on OSX/IOS devices, there is no auth in the cp browser
But how? Authorization is requested after processing the CP:
if (captivePortal()) return; // If captive portal redirect instead of displaying the page
if (!handleRequest()) return;
I'll check this in a couple of days.
CaptivePortal() is just a redirect, so it goes to handleroot / which is auth and an invalid response for the cp browser.
I was looking at the port code yeah we are not checking host port from header, that might be fixable, but makes sense to just to skip cp checks entirely in not on ap.. since its irrelevant, so that will probably get added instead. But ideally a proper fix would be required if we wanted AP+STA mode, it works in some setups but mostly is problematic.
I will try to merge this today with some exception added that if cpenabled, AUTH will be ignored on ap
This PR adds HTTP Digest Authentication (or revives the dead feature). May not work with some Android native webview browsers (Upon tapping "Sign in to network" notifications).