<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On one hand we wouldn't want to ruin Apple user's UX, but the portal
is more than a read and go. People might want to interact and
navigate from it, so even if we played with the accessibility of
apple.com after login, we would need to eventually grant this login
and the page would be gone. <br>
<br>
Besides, the little browser Apple uses to show the login page is not
a full web browser and might not be the best to view the portal
page.<br>
<br>
Could we think of an intermediate state where, if the first request
is <a moz-do-not-send="true"
href="http://www.apple.com/library/test/success.html">http://www.apple.com/library/test/success.htm</a>l,
we log the user in and allow all traffic on ports other than web,
but the next web request (hopefully from a browser) would show the
portal page?<br>
<br>
Any other ideas?<br>
<br>
That feature is really annoying for us community networks!<br>
<br>
Thanks,<br>
Geneviève<br>
<br>
<br>
On 11-08-26 10:32 AM, Max Horváth wrote:
<blockquote
cite="mid:2E8E29F4-C003-41F0-8D51-57AA5894086F@maxhorvath.com"
type="cite">I would strongly suggest to not deactivate the auto
login feature for Apple products by fooling the devices that they
could reach the Apple server.
<div><br>
</div>
<div>Apple device users are used to the auto login feature for
WiFi networks with captive portals. So would basically screw the
UX they are used to.</div>
<div><br>
</div>
<div>If you really need to display the portal information, you
either should manipulate the accessibility of <a
moz-do-not-send="true"
href="http://www.apple.com/library/test/success.html">http://www.apple.com/library/test/success.html</a>
after the login was successful. Then you could redirect to the
portal instead of the login page. Or you should place
information of the portal onto the login page.</div>
<div><br>
</div>
<div>My 2 cents,</div>
<div>Max</div>
<div><br>
<div>
<div>On 25.08.2011, at 19:40, Geneviève Bastien wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#ffffff" text="#000000"> Thanks for the
answer, but that is not the issue. It is more Apple
products bypassing the portal page, the whole login
process is all fine.<br>
<br>
I found this: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://blogs.oucs.ox.ac.uk/networks/2009/10/12/fixing-the-iphone-os-wifi-auto-login-problem/">http://blogs.oucs.ox.ac.uk/networks/2009/10/12/fixing-the-iphone-os-wifi-auto-login-problem/</a>
Which may suggest that we could bypass the auto-login
feature from the server side by answering the request with
the expected output. The user will then have to open a
browser page to see the actual login and portal pages.<br>
<br>
Geneviève<br>
<br>
<br>
On 11-08-25 01:12 PM, acv wrote:
<blockquote cite="mid:20110825171216.GB36607@miniguru.ca"
type="cite">
<pre wrap="">Marcos' comments below are not completely accurate, the ping was not a test itself,
in fact the gateway never bothered reading the response... The idea was to cause
the client to generate activity. Then activity (measured in bytes received from
client since last polling) was used.
In src/firewall.c, fw_sync_with_authserver() implements the timeout logic, it includes
this tidbit:
/* Ping the client, if he responds it'll keep activity on the link.
* However, if the firewall blocks it, it will not help. The suggested
* way to deal witht his is to keep the DHCP lease time extremely
* short: Shorter than config->checkinterval * config->clienttimeout */
ping was to be a BACKUP way of generating activity but using DHCP as suggested here is
much more reliable.
Cheers,
Alexandre
On Thu, Aug 25, 2011 at 01:06:29PM -0300, Marcos Tadeu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Date: Thu, 25 Aug 2011 13:06:29 -0300
From: Marcos Tadeu <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:marcos@v2r.com.br"><marcos@v2r.com.br></a>
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wifidog@listes.ilesansfil.org">wifidog@listes.ilesansfil.org</a>
Subject: Re: [isf-wifidog] Wifidog, portal page and Apple auto-login
Can you ping the Apple products from wifidog captive portal machine,
after login?
If not, it is the problema: wifidog need to ping client to know that it
is alive. If an firewall drop the ping, wifidog consider it dead. And...
pouf.
On 08/25/2011 12:38 PM, Geneviève Bastien wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello all,
We have a problem with the portal page and Apple products and their
auto-login feature. Right now, when any iOs product and now Lion
connects to a wifidog router, they are shown the login page right
away, and the minute they have access to the internet (<a moz-do-not-send="true" href="http://apple.com">apple.com</a>
site), pouf! it's gone, so they never see the portal page.
But the portal page is really important to us and this situation is
really annoying (40 to 50% of our users use Apple products!).
Did anyone come up with a solution to this? Or do you know any
captive portal solution that did? Any ideas on the topic? (putting
<a moz-do-not-send="true" href="http://apple.com">apple.com</a> in the walled garden is not a viable option)
Thanks,
Geneviève
_______________________________________________
WiFiDog mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
WiFiDog mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a>
</pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
WiFiDog mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a></pre>
</blockquote>
</blockquote>
<br>
</div>
_______________________________________________<br>
WiFiDog mailing list<br>
<a moz-do-not-send="true"
href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a><br>
<a class="moz-txt-link-freetext" href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a></blockquote>
</div>
<br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
WiFiDog mailing list
<a class="moz-txt-link-abbreviated" href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a>
<a class="moz-txt-link-freetext" href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a></pre>
</blockquote>
<br>
</body>
</html>