Modify wifi-connect page to accept additional parameters


#1

Hello!

The resin-wifi-connect page already accepts the network’s SSID and PW. I’d like to add additional fields, e.g. a username and password for accessing a web app, into the HTML page that can be input by the user and perhaps stored in a local PostgreSQL database.

Because I am installing wifi-connect during a Dockerfile build on resinOS, it shows up as an executable module and it’s tough to discern what’s happening under-the-hood.

Any suggestions on how to achieve this?

Thanks.


#4

This is all possible. The best way currently to achieve this is to run your web application that will handle the additional fields to be passed, and then run WiFi Connect on a different port than 80 and use its JSON API. Here is an example project which you need to check its sources to see how this could be achieved: https://github.com/resin-io-playground/balena-wifi-connect-api

Again if you have any questions regarding this please ping me.

Good luck!


#8

Hello, thank you for pointing me toward this JSON API example.
I implemented the example verbatim, the build was successful, and the Access Point and Flask server seem to run at startup. Here is the Balena-Cloud dashboard’s Logs output:

25.11.18 21:59:40 (-0800) web-app /sbin/udevd
25.11.18 21:59:46 (-0800) web-app * Running on http://0.0.0.0:80/ (Press CTRL+C to quit)
25.11.18 22:04:59 (-0800) wifi-connect WiFi device: wlan0
25.11.18 22:05:00 (-0800) wifi-connect Access points: ["network1", "network2", etc...]
25.11.18 22:05:00 (-0800) wifi-connect Starting access point...
25.11.18 22:05:01 (-0800) wifi-connect Access point 'WiFi Connect' created
25.11.18 22:05:01 (-0800) wifi-connect Starting HTTP server on 192.168.42.1:45454

However, once I connect my smartphone to the AP, I repeatedly get 204 error codes from the web-app, and I cannot reach 192.168.42.1, 192.168.42.1:80, nor 192.168.42.1:45454 through a browser. Here is the output after connecting to the AP:

25.11.18 22:06:01 (-0800) web-app 192.168.42.93 - - [26/Nov/2018 06:06:01] "GET /generate_204 HTTP/1.1" 404 -
25.11.18 22:06:01 (-0800) web-app 192.168.42.93 - - [26/Nov/2018 06:06:01] "GET /gen_204 HTTP/1.1" 404 -
25.11.18 22:06:02 (-0800) web-app 192.168.42.93 - - [26/Nov/2018 06:06:02] "GET /generate_204 HTTP/1.1" 404 -

And so on…
The Flask error code 204 indicates “No Content”, so I am inclined to think this is related to where the web-app’s static files are being pointed to? But haven’t managed to clear up the 204/404 errors. I could also be way off the mark.

Any ideas how to sort this out? Thanks.


#9

The /generate_204 requests are triggered by the phone OS to determine whether the network is behind a captive portal. The flask server properly returns 404 which indicates to the phone that there is a captive portal. Different types of phones would use a different URL to detect this. That is to say everything is alright with the web server returning 404 on those requests. This is also the case when running vanilla wifi-connect - it will return 404 on those requests.

Please let me know if you have any questions.


#10

@majorz Thanks very much for the clarifications. If that is the case and everything is working properly, then why is the index.html not being served to my mobile device’s browser? I am unable to view a page where I can choose a wifi network / input a password. I’d ultimately like to edit the static files to input custom data.


#11

@dysri the index page should be loaded. I will provision a device now to check whether I can reproduce any issues and ping you back.


#12

@dysri I found the issue. I was incorrect about the 404 response. The proper way of handing this is to return a redirect response (302 Found) to the index page on 192.168.41.1 for any other locations than this IP (that is the HTTP host header). Fixing that will need inserting a Flask middleware that checks the host header and does the redirect. I will check how this should be done.


#13

@dysri I committed a fix for that. Please let me know how that works for you and if you have any further questions.


#15

Your fix seemed to do the trick, thanks very much for your support.

I’m now able to use custom input fields!