Hi,
Nack on that patch, see below.
From: Pasi Sjöholm <pasi.sjoh...@jollamobile.com>
Sometimes captive portal intercepts status_url-query without doing
302-redirect. It makes no sense to request browser with NULL as an url,
therefore we need to use the status_url.
---
src/wispr.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/wispr.c b/src/wispr.c
index c4fcd60..d092630 100644
--- a/src/wispr.c
+++ b/src/wispr.c
@@ -724,10 +724,19 @@ static bool wispr_portal_web_result(GWebResult *result,
gpointer user_data)
&str)) {
portal_manage_status(result, wp_context);
return false;
- } else
- __connman_agent_request_browser(wp_context->service,
+ } else {
+ if (!wp_context->redirect_url) {
+ __connman_agent_request_browser(
+ wp_context->service,
+ wispr_portal_browser_reply_cb,
+ wp_context->status_url, wp_context);
+ } else {
+ __connman_agent_request_browser(
+ wp_context->service,
wispr_portal_browser_reply_cb,
wp_context->redirect_url, wp_context);
+ }
+ }
break;
case 302:
It's not a good idea to expose the status url. It's an internal url used
for testing the connection status,
the fact it's also related to wispr is only because both process were
easier to be implemented together
rather than separately.
Maybe we could change the documentation of RequestBrowser() Agent method
so that
if the url is null, browser will have to use whatever default url it wants.
Tomasz
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
