Portal internet access on successful connection.

[feliks912]

Hello Mr. Hieromon, thank You for Your work. This is such an amazing library our college professor wants to use it it as a de-facto ESP solution for our current, and future projects.

I have stumbled upon the following problem. The code below sets Autoconnect up so /_ac/googleLogin is displayed upon a successful WiFi connection. There, a button with Javascript copies a defined string to clipboard and redirects users to an outside URL, i.e. YouTube.com. It works except users don't have internet connection when they click the button, and the page can't load.

Assuming users don't use LTE in the process, and rely only on the connection made to the ESP SoftAP when accessing the site, can the ESP tunnel internet connection from a connected network to the existing softAP, retaining full captive portal functionality (specifically login to network prompt)? I'm looking to pass the internet connection to the user.

I've read Preserving AP mode and Inside AutoConnect::begin. Preserve AP only works when autoRise is set to false, which stops Captive portal's 'login to network', a feature we are looking for. Is there a way to retain it, keep the portal active after a connection to the network is made (retainPortal), and enable internet access such that, when the user clicks the URL on the success screen, they can access internet sites?

A practical use-case would be authenticating limited-input devices with Google where, upon a successful internet connection, ESP makes an API request, gets the keys, edits the URL and STRING variables in text json and allows users to access Google's device authentication portal through one click.

I played around with re-configuring the AP after Portal.begin() returns, but that disconnects the user even when all parameters are the same as the one they are connected to (ip, ssid, password, gateway).

#include <WiFi.h>
#include <WebServer.h>
#include <AutoConnect.h>
#include <WiFiManager.h>

#define AUTOCONNECT_URI_ONSUCCESS "/_ac/googleLogin"

WiFiManager Manager;
WebServer Server;
AutoConnect Portal(Server);
AutoConnectConfig Config;


//-------json-------

static const char JSON_PAGES[] PROGMEM = R"raw(
{
  "uri": "/_ac/googleLogin",
  "title": "Authenticate device",
  "menu": true,
  "element": [
    {
      "name": "login",
      "type": "ACButton",
      "value": "Authenticate",
      "action": "minRed('UNIQUE_CODE','UNIQUE_URL')"
    },
    {
      "name": "copyToClipboard",
      "type": "ACElement",
      "value": "<script>function minRed(e,s){let o=document.createElement('textarea');o.value=e,document.body.appendChild(o),o.select(),document.execCommand('copy'),document.body.removeChild(o),location.href=s}</script>"
    }
  ]
}
)raw";


//-------setup-------

void setup() {
  Manager.resetSettings();

  Serial.begin(115200);

  Portal.load(FPSTR(JSON_PAGES));

  Config.retainPortal = true;
  Portal.config(Config);
  
  if (Portal.begin()) {
    Serial.println("WiFi connected: " + WiFi.localIP().toString());
  }
}


//-------loop-------

void loop() {
    Portal.handleClient();
}

Thank You very much in advance,
Feliks Mihelj

[Hieromon]

@feliks912, Thank you for using AutoConnect. I will explore as some solutions as possible to meet your needs.
First, let's talk about the WiFi SoftAP and WiFi Station gimmicks built into the ESP module. This will help us understand your use case as accurately as possible for me.

The ESP32 (also ESP8266) has a WiFi implementation with two different roles. One realizes a Soft AP and the other constitutes a WiFi station. The TCP stacks of Soft AP and the WiFi station are independent and have separate IP addresses.

In the situation where you open a captive portal with the ESP module, the IP address of the ESP module is in the following state.

The connection request is issued from the web page displayed on your client device. (i.e. HTTP GET) The response to this GET request is pending for the duration of the connection attempt.
If the connection is successful, the status of the peripherals around your client device will look as follows:

When a client device successfully connects to a WiFi access point, the ESP32's WiFi Station will have a data link between your requested access points. However, your client device will still maintain a data link to the ESP32 WiFi AP (SoftAP). And these two routes do not belong to the same network segment.

Some constraints should be clarified from your request

1. Integration of ESP module's built-in SoftAP and WiFi Station

   As explained above, the SoftAP and WiFi Station of the ESP module are hardware separated. From the outside, they appear to be integrated components, but in fact, they are individual components stuck together. It is neither a router nor a bridge.
   If you need to relay incoming client requests to SoftAP to a real WiFi access point in your environment (which probably also has routing capabilities to go out to the internet). Then you need to intentionally pass packets arriving at SoftAP to the TCP stack on the WiFi Station side of the ESP module. This means we need to implement the routing functionality as software.

   So, here is your question below.

   can the ESP tunnel internet connection from a connected network to the existing softAP, retaining full captive portal functionality (specifically login to network prompt)?

   It would be possible but is beyond the scope of AutoConnect's functionality. It is literally a router device.
   On the other hand, Espressif implements the ESP-MESH protocol based on a similar focus to the theme you have presented.

   

   The Station Interface shown above is the WiFi Station component that functions in WiFi_STA_Mode; SoftAP is the softAP Interface shown above. As you can see, they only work together at the application layer higher up in the TCP stack layer.
   Also, the equivalent of the Root Node in the diagram above is your supposed ESP module, which you can assume is driven by some software with functionality similar to AutoConnect. And the Leaf Node equivalent is the user's client device. We can see as your use case as a truncated topology of the Intermediate Parent Node above.
   However, the only protocol we can use is TCP/IP.

2. How AutoConnect Enables Captive Portals

   Mobile devices such as Android and iPhone, and tablets and PCs with WiFi, when they establish a data link with a WiFi access point, they incidentally verify their transparency to the Internet.

Implementation Models

I have illustrated below what I understand based on your reference. Is this what you are trying to say?

1. If my understanding of the above diagram is correct, what is the role of the ESP module?
   Is it a gateway? Or is it something else?
   I am not sure what you want the ESP module to do. Could you please explain again?

2. What are the operations that real users experience and what behavior do they expect from the ESP module?

   A practical use-case would be authenticating limited-input devices with Google where, upon a successful internet connection, ESP makes an API request, gets the keys, edits the URL and STRING variables in text json

   This is understandable. But I'm not sure what's next.

   allows users to access Google's device authentication portal through one click.

   Which element in the above diagram accesses the OAuth2.0 endpoint? And what is the sequence you would like to see?

I am sure my understanding has not caught up with you, so please bear with me on that. It would be helpful if you could provide a little more specific flow.

Thank you.

[Hieromon]

@feliks912
After rereading your post I realize I may be spectacularly misunderstanding.

Do you simply want to configure a so-called device flow using an ESP module (i.e., a devices that have limited input capabilities with an embedded ESP module) based on the premise of OAuth2.0 RFC6749?

If so, in the quote from the RFC below, where does the captive portal produced by SoftAP of the ESP module appear in (A) through (D)? And how does that relate to following your mention? In particular, what does ESP tunnel internet connection mean?

Assuming users don't use LTE in the process, and rely only on the connection made to the ESP SoftAP when accessing the site, can the ESP tunnel internet connection from a connected network to the existing softAP, retaining full captive portal functionality (specifically login to network prompt)? I'm looking to pass the internet connection to the user.

 +----------+                                +----------------+
 |          |>---(A)-- Client Identifier --->|                |
 |          |                                |                |
 |          |<---(B)-- Device Code,      ---<|                |
 |          |          User Code,            |                |
 |  Device  |          & Verification URI    |                |
 |  Client  |                                |                |
 |          |  [polling]                     |                |
 |          |>---(E)-- Device Code       --->|                |
 |          |          & Client Identifier   |                |
 |          |                                |  Authorization |
 |          |<---(F)-- Access Token      ---<|     Server     |
 +----------+   (& Optional Refresh Token)   |                |
       v                                     |                |
       :                                     |                |
      (C) User Code & Verification URI       |                |
       :                                     |                |
       v                                     |                |
 +----------+                                |                |
 | End User |                                |                |
 |    at    |<---(D)-- End user reviews  --->|                |
 |  Browser |          authorization request |                |
 +----------+                                +----------------+

Or are you assuming the above sequence (C) as a network connection from the end user's secondary device to the ESP's SoftAP? And you want to use a captive portal gimmick to automatically pop up a login page and redirect to a validation URI?
So you want to implement all sequences (A) through (F) except (D) in an ESP module embedded in a device client?

If so, the [End User at Browser] device (i.e., secondary device) shown in sequence (C) and (D) above would have two different segment IP addresses, one for the ESP's SoftAP connection and one for the Authorization Server connection (i.e., IP address connected to the Internet). Can your secondary device do that trick?

[feliks912]

Thank You for Your answer Mr. Hieromon.

You are exact on the second one. The ESP32 is the limited device. We need it to use Google API to talk to Firebase and handle data.

The operational sequence is as follows:

• ESP32 is authenticated and connected to the Home WiFi, user gets redirected to /_ac/googleLogin
• ESP32 sends a POST request to Google's servers, gets a response with unique ID and unique LINK ( steps A & B )
• Script changes page JSON, replacing it with unique ID, unique LINK ( step C )
• User gets redirected to /_ac/googleLogin* with a JavaScript button with unique ID and unique LINK ( step C )
• User clicks the button, unique ID goes to clipboard and user is sent to LINK, https://accounts.google.com/o/oauth2/device/usercode?flowName=DeviceOAuth (but not always that site). ( step D )
• User pastes the code from their clipboard
• ESP32 is authenticated. E and F happen later in the process, outside of AutoConnect.

A caricature of the implementation model:

User must access google.com without leaving the portal. I don't know if I must do that in software or if MESH can be supported using AutoConnect / in conjunction with AutoConnect's portal running. Seems like a rudimentary function, but it's timing and the fact the user can't be disconnected from the AP in the first place that, as far as I see, makes it complex.

Is it possible to do such a thing while also using AutoConnect?

Thank You for your detailed approach.
Feliks Mihelj

*Alternatively user gets directed to a temporary page until Google responds with the codes, after which they get sent to /_ac/googleLogin

[Hieromon]

Thanks for the revised figures. I think your question and what I see as the problem came pretty close.

Here are some obvious problems that we should solve before we try to implement this model:

In order to keep the captive portal auto-popup alive, the DNS server provided by AutoConnect must be kept alive even if ESP32 successfully connects to the Home WiFi. As a result, all A records in response to DNS lookups requested from the browser device's OS will point to the ESP32 AP's IP address.

Thus, the HTTP request in step (D) on the browser device will not reach the Google device authentication page address.
In addition to that, this is also a problem related to cross-segment access. The behavior of browsers opened by the device in a captive portal state is different than a normal state. It cannot be accessed across segments. Security is enabled. Therefore, even if the response page returned by AutoConnect contains a cross-segment link, it may be rejected. Since this depends on the OS implementation of the browser device, it is not possible to specify what the behavior will be. I don't think that can be solved by a simple redirect.

So, our only remaining option is to relay HTTP(S) requests arriving at SoftAP to the Station via the application layer. The same is true for the response.

It traps HTTP(S) requests arriving at SoftAP from browser devices and relays them to Station. Returns the response returned to the Station to the browser device. This process could be implemented using the request handler of the WebServer class and HTTPClient (HTTPSClient) library. Also, it must be implemented in a sketch as an external component of AutoConnect. If HTTP requests from browser devices can be narrowed down to specific FQDNs, the trap-and-relay process may be further reduced. I believe it can coexist with AutoConnect.

I'll think about it a little more, but I'm pretty sure we'll be implementing a pseudo-bridge on ESP32.
However, there is also the simple question of whether auto-popups for captive portals should be taken so seriously. The captive portal state will limit the content of the client page quite a bit, even JavaScript, for example.