[ipilcher]

I have added the following to my Apache reverse proxy config:

Header always set Access-Control-Allow-Headers “*”
Header always set Access-Control-Allow-Origin “*”

And curl shows that the headers are being sent back by the proxy:

< HTTP/1.1 401 Unauthorized
< Date: Mon, 10 Jul 2023 21:37:45 GMT
< Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Origin: *
< WWW-Authenticate: Basic realm=”OpenSprinkler”
< Content-Length: 381
< Content-Type: text/html; charset=iso-8859-1

I’m still seeing the same behavior from the app, however, telling me to check the IP or port.

[ipilcher]

Seeing exactly the same thing here. My Apache logs show the following when I try to connect.

166.177.122.80 – – [10/Jul/2023:09:12:08 -0500] “OPTIONS /opensprinkler//jo?pw=d41d8cd98f00b204e9800998ecf8427e HTTP/1.1” 401 381
166.177.122.80 – – [10/Jul/2023:09:12:08 -0500] “OPTIONS /opensprinkler/ HTTP/1.1” 401 381
166.177.122.80 – – [10/Jul/2023:09:12:29 -0500] “-” 408 –

[ipilcher]

You can put it in the “Change IP” field in the Android app – FQDN:port

[ipilcher]

Oh sorry, just put the following for the IP: my.domain.com/os

Ah, that makes sense. I think you need to rename that field.

Thanks again!

[ipilcher]

Yes, the app works well with subdirectory type proxies. In fact, it’s what I have been using for over two years now 🙂

But how do you tell the app about the subdirectory?

[ipilcher]

You can even install the latest build of the app from here: https://build.phonegap.com/apps/1373249/install if you want to test.

Worked the first time. Unbelievable!

Now I have a question about your setup … since your proxy is at https://my.domain.com/os (rather than just https://my.domain.com), are you able to use the app? If so, how do you do that? (I.e. where does the “/os” go on the “New Device” screen?)

Thanks!

[ipilcher]

I’m pretty much convinced that the proxy isn’t adding the slash. I managed to use wireshark to decrypt the SSL traffic between the app and the proxy, and I can see the app sending the request with the extra slash:

GET /js/?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1
Host: www.penurio.us:32697
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; A0001 Build/KTU84Q) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Mobile Safari/537.36
Accept-Encoding: gzip,deflate
Accept-Language: en-US
X-Requested-With: com.albahra.sprinklers

HTTP/1.1 200 OK
Date: Thu, 27 Aug 2015 22:11:52 GMT
Content-Type: application/json
Access-Control-Allow-Origin: *
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Connection: close
Transfer-Encoding: chunked

d
{"result":32}
0

I also connected to the phone with Chrome, as you suggested, and the Console tab shows a bunch of errors like:

Failed to load resource: net::ERR_FAILED https://www.penurio.us:32697/js/?pw=f7a9f061ae223e7ed166a73abe2abd8a

(With the extra slash.)

On the network tab, however, the URLs don’t have the slash.

And ….. son of a B, it works on a different phone! It looks like the phone OS is munging the URLs for some reason.

[ipilcher]

Regarding the extra slash though, it doesn’t seem to be an issue when querying the controller. In other words, for me both /js/?pw and /js?pw work and return the expected reply. Therefore, I am not even sure if that is the issue.

That’s really interesting. Are you saying that you don’t get the failure on the second attempt with curl?

[pilcher@ian ~]$ curl http://172.31.252.3/js?pw=f7a9f061ae223e7ed166a73abe2abd8a
{"sn":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"nstations":16}[pilcher@ian ~]$ 
[pilcher@ian ~]$ curl http://172.31.252.3/js/?pw=f7a9f061ae223e7ed166a73abe2abd8a
{"result":32}[pilcher@ian ~]$

Can you check that before I do all the Android debugging stuff?

[ipilcher]

I agree that it’s very weird. I also thought that the proxy was adding the slash, but the logs from the proxy show that it isn’t so:

172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /js/?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 13
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jc?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 349
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jo?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 384
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jp?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 62
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jn?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 236
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jo?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 384
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /js/?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 13
172.31.253.140 - - [27/Aug/2015:15:14:54 -0500] "GET /jc?pw=f7a9f061ae223e7ed166a73abe2abd8a HTTP/1.1" 200 349

Here is the proxy configuration:

Listen 32697

<VirtualHost *:32697>

        ServerName www.penurio.us:32697

        ErrorLog /etc/httpd/logs/sprinklers-proxy_error_log
        TransferLog /etc/httpd/logs/sprinklers-proxy_access_log
        LogLevel warn

        NSSEngine on
        NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
        NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
        NSSNickname "www.penurio.us - StartCom Ltd."

        ProxyPass / http://172.31.252.3/
        ProxyPassReverse / http://172.31.252.3/

</VirtualHost>

And yes, the slash is not present when using the browser UI (including when using the browser UI from the Android device).

[ipilcher]

Ah, cool. I was going by the URL from the Using a Different Server for UI Assets article. You might want to update that.

[ipilcher]

I understand what you are saying but first, I’ve already outlined available apps for the desktop which means it’s not restricted to mobile phones and tablets. Please refer to the list of apps that I have linked.

Aah. I didn’t realize that the app could run in a desktop browser. Interesting.

Second, not sure how a user managing his own DNS would be more secure than our DNS. We take every security precaution with our DNS hosting accounts and use CloudFlare for added protection.

The issue is that a users controller/browser could be fooled into downloading malicious versions of the UI elements. SSL (with certificate validation) would prevent this, since the attacker (presumably) wouldn’t have the private key for the server certificate.

Regarding the SSL/TLS support, no Arduino could support this and instead depends on other measures for security. We are looking at cloud access instead of port forwarding in which case we will use AES 128 for communication. In the mean time, you may setup a reverse proxy that adds SSL and even BASIC auth if you wish, as the app does support this.

Does the controller download the UI elements and then send them to the client, or does it just embed links into the HTML it sends to the clients? If it’s the latter, is there a reason that https://ui.opensprinkler.com/js wouldn’t work?

I was actually thinking about going the reverse proxy route, but I wasn’t aware that the “mobile” app supported SSL. (Why would it if the controller itself doesn’t?) That’s really good to know, and it wish that it were stated more prominently (although I have no idea where it should be so stated).

I guess the other option is to go the Rasberry Pi route. Decisions, decisions.

Thanks for the response!

[ipilcher]

So what is the license?

Simply putting the source code on github does not make something open source; it has to actually be licensed under an open source license, which most people interpret as meaning a license that has been accepted by the Open Source Initiative.

[ipilcher]

I strongly suggest that you reconsider this decision. In fact, I strongly suggest that you host the UI elements on the controller by default. (If 3MB of content is too much for the SD card, it’s arguably already too small.)

As it stands, you’re one DNS hijack plus a browser vulnerability away from being a vector for compromising your users’ systems.

And no, a mobile app is not always a viable alternative. My mother, who is the main “plant person” in our household, doesn’t have a smartphone or tablet. If I were to need remote access to the controller it would currently be done via SSH, VNC, and a browser. Given the lack of SSL/TLS support, I can’t see myself ever exposing this thing to the Internet.

[Author]

Posts