JS library modifications

[hryamzik]

I've made some modifications to the JS library and scripts around it to accommodate PAP passwords and for better https support.

Scripts now check the $HS_UAMUISSL variable and if it's set to on defines chilliwww as "https:\/\/$HS_UAMALIASNAME.$HS_DNS_DOMAIN:$HS_UAMUIPORT" instead of chilliwww="http:\/\/$HS_UAMLISTEN:$HS_UAMPORT" so that a valid certificate could be used. This assumes that this name (like hotspot.example.com) is set to the $HS_UAMLISTEN address (10.1.0.1) and there's a certificate generated for this name. This is proved to work with startssl free certificates..

I have also made changes to chilli.js to work with https, in fact that's only about src url:

script.src = (location.protocol == 'http:' ? ('http://'+queryObj['uamip']+':'+queryObj['uamport']+'/') : decodeURIComponent(queryObj['ssl']) ) + 'www/chillijs.chi';

I was very surprised to see unencrypted traffic by default and would really like to push these changes to the code and to add some configuration examples as well. Can I just put it all in a single pull request?

I'm especially not sure about the PAP support, shall I make a variable for it? Here's the diff if it makes any sense:

diff -r -U 0 www.orig/ChilliLibrary.js www/ChilliLibrary.js
--- www.orig/ChilliLibrary.js   2014-11-25 15:33:21.000000000 +0300
+++ www/ChilliLibrary.js    2014-11-25 17:43:19.000000000 +0300
@@ -333 +333 @@
-       var logonUrl = chilliController.urlRoot() + 'logon?username=' + escape(username) + '&response='  + resp.response;
+       var logonUrl = chilliController.urlRoot() + 'logon?username=' + escape(username) + '&password='  + resp.response;
diff -r -U 0 www.orig/chilliController.js www/chilliController.js
--- www.orig/chilliController.js    2014-11-25 15:33:21.000000000 +0300
+++ www/chilliController.js 2014-11-25 18:07:58.000000000 +0300
@@ -278 +278 @@
-       script.src = 'http://'+chilliController.host+':'+chilliController.port+'/www/chilliform.chi';
+       script.src = (( chilliController.ssl ) ? "https" : "http") + '://'+chilliController.host+':'+chilliController.port+'/www/chilliform.chi';
diff -r -U 0 www.orig/chilliform.chi.sh www/chilliform.chi.sh
--- www.orig/chilliform.chi.sh  2014-11-25 15:33:21.000000000 +0300
+++ www/chilliform.chi.sh   2014-11-25 18:00:39.000000000 +0300
@@ -13 +13,6 @@
-chilliwww="http:\/\/$HS_UAMLISTEN:$HS_UAMPORT"
+if [ "$HS_UAMUISSL" = "on" ] 
+    then
+    chilliwww="https:\/\/$HS_UAMALIASNAME.$HS_DNS_DOMAIN:$HS_UAMUIPORT"
+else
+    chilliwww="http:\/\/$HS_UAMLISTEN:$HS_UAMPORT"
+fi
diff -r -U 0 www.orig/chillijs.chi.sh www/chillijs.chi.sh
--- www.orig/chillijs.chi.sh    2014-11-25 15:33:21.000000000 +0300
+++ www/chillijs.chi.sh 2014-11-25 17:58:35.000000000 +0300
@@ -15,2 +15,11 @@
-echo "chilliController.host = '$HS_UAMLISTEN';"
-echo "chilliController.port = $HS_UAMPORT;"
+if [ "$HS_UAMUISSL" = "on" ] 
+    then
+    echo "chilliController.ssl = true;"
+    echo "chilliController.host = '$HS_UAMALIASNAME.$HS_DNS_DOMAIN';"
+    echo "chilliController.port = $HS_UAMUIPORT;"
+
+else
+    echo "chilliController.host = '$HS_UAMLISTEN';"
+    echo "chilliController.port = $HS_UAMPORT;"
+fi
+

PS: I've also made some scripts for openwrt installation including heartbeat support based on nas ID, init scripts and importing values from the UCI-based config but I've no idea what's the best way to share this.

[jobezic]

Good work! Personally i think that the concept of showing the captive portal by redirection is bad (the host where coova-chilli is running must have a trusted certificate to work with SSL and most mobile browsers does not allow to accept a no-trusted certificate..). So i think to develop something like a mobile app that replaces the captive portal (starting from CoovaAX for example..).

[hryamzik]

@pinkra, not sure if you got the way I've implemented this. Take a look, hotspot.example.com is resolved 10.1.0.1 and has a valid certificate from startssl.com. You see, now warnings from the browser.

As public wireless networks are usually not encrypted this is the only way to protect usernames and passwords from being sniffed.

UPD: to be clear, it's impossible to put https on you main portal without these modifications because it leads to loading unsecured content on a secured page and browsers rise warnings about this. So once you set up https on your login pages (and if not – username and password are transferred unencrypted over unprotected wi-fi network) you have to set up https for all the coova sources stored on the hotstop as well.

[jobezic]

Yes, my previous considerations were generic and not referred to your specific work that i appreciate. I suggest you to make a pull request for your fixes.

[hryamzik]

Perfect, so I'll make a single pull request for all the mentioned things a bit later. I'll also make PAP passwords optional.

[sevan]

Can this ticket be closed?

[hryamzik]

Yep, sorry, no time for PAP support, I'll make a pull request if I'll find time for it.