Firefox continually reloads page when "browser-based" basic auth is used

[ipilcher]

I use an Apache reverse proxy to provide TLS and (basic) authentication for my OpenSprinkler setup. The same Apache server also hosts the web UI files (in a different virtual server).

When I access the OpenSprinkler web UI from Firefox, I am first asked to authenticate. After I do that successfully, I am presented with the OpenSprinkler UI page, which endlessly crashes and reloads. The Firefox debugger shows this error message.

Uncaught (in promise) DOMException: The operation is insecure

It claims that the error is occurring at js/jqm.js:3, but that isn't useful, as that line is more than 32,000 characters long. After replacing jqm.js with a "beautified" version, the Firefox debugger no longer gives me a location for the exception.

There are no failed network requests. (I had to add a couple of symlinks within the UI content tree to make Firefox's built-in favicon loader happy.)

Here is the Apache configuration for the reverse proxy.

<VirtualHost 172.31.255.2:443>
        ServerName sprinklers.penurio.us
        ServerAlias sprinklers
        ErrorLog /etc/httpd/logs/sprinklers_error_log
        TransferLog /etc/httpd/logs/sprinklers_access_log
        LogLevel info
        SSLEngine on
        SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
        SSLHonorCipherOrder on
        SSLCipherSuite PROFILE=SYSTEM
        SSLProxyCipherSuite PROFILE=SYSTEM
        SSLCertificateFile /etc/pki/tls/certs/sprinklers.penurio.us.crt
        SSLCertificateKeyFile /etc/pki/tls/private/sprinklers.penurio.us/sprinklers.penurio.us.key
        <Location />
                AuthType Basic
                AuthBasicProvider ldap
                AuthName OpenSprinkler
                AuthLDAPUrl ldap://127.0.0.1/cn=users,cn=accounts,dc=penurio,dc=us?uid
                AuthLDAPCompareAsUser on
                Require ldap-group cn=sprinklers,cn=groups,cn=accounts,dc=penurio,dc=us
                ProxyPass http://172.31.252.3/ timeout=1200
                ProxyPassReverse http://172.31.252.3/
                Header always set Access-Control-Allow-Origin https://osp-ui.penurio.us
                Header always set Access-Control-Allow-Credentials: true
        </Location>
</VirtualHost>

And here is the Apache configuration for the UI content.

<VirtualHost 172.31.255.2:443>
        ServerName osp-ui.penurio.us
        ServerAlias osp-ui
        DocumentRoot /var/www/opensprinkler
        ErrorLog /etc/httpd/logs/sprinklers_error_log
        TransferLog /etc/httpd/logs/sprinklers_access_log
        LogLevel info
        SSLEngine on
        SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
        SSLHonorCipherOrder on
        SSLCipherSuite PROFILE=SYSTEM
        SSLProxyCipherSuite PROFILE=SYSTEM
        SSLCertificateFile /etc/pki/tls/certs/osp-ui.penurio.us.crt
        SSLCertificateKeyFile /etc/pki/tls/private/osp-ui.penurio.us/osp-ui.penurio.us.key
        # This stuff is from the OpenSprinkler documentation
        #Header set Access-Control-Allow-Origin "*"
        Header always set Access-Control-Allow-Origin https://sprinklers.penurio.us
        Header always set Access-Control-Allow-Credentials: true
        AddEncoding x-gzip .cgz .jgz
        AddType text/css cgz
        AddType text/javascript jgz
</VirtualHost>

This issue does not occur in Google Chrome, but it seems that it is likely CORS-related, so whatever restriction is breaking the UI in Firefox today will probably come to Chrome at some point. This issue may also have the same root cause as this issue, which prevents the Android app from working with TLS and authentication.

[ipilcher]

Seems to have been fixed by the changes to my Apache configuration in issue #274 . Closing.

[ipilcher]

It appears that I was premature when I closed this issue. I was just able to reproduce this issue, and I may actually have captured some useful information about the exception.

Here is the current configuration of my reverse proxy.

<VirtualHost 172.31.255.2:443>
    ServerName sprinklers.penurio.us
    ServerAlias sprinklers
    DocumentRoot /var/www/opensprinkler
    ErrorLog /etc/httpd/logs/sprinklers_error_log
    TransferLog /etc/httpd/logs/sprinklers_access_log
    LogLevel info
    SSLEngine on
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder on
    SSLCipherSuite PROFILE=SYSTEM
    SSLProxyCipherSuite PROFILE=SYSTEM
    SSLCertificateFile /etc/pki/tls/certs/sprinklers.penurio.us.crt
    SSLCertificateKeyFile /etc/pki/tls/private/sprinklers.penurio.us/sprinklers.penurio.us.key
    <LocationMatch "^(?!/ui/)">
        # OPTIONS requests must succeed (return 200 or 204) for CORS to work,
        # so don't require authentication for those requests
        <If "%{REQUEST_METHOD} != 'OPTIONS'">
            AuthType Basic
            AuthBasicProvider ldap
            AuthName OpenSprinkler
            AuthLDAPUrl ldap://127.0.0.1/cn=users,cn=accounts,dc=penurio,dc=us?uid
            AuthLDAPCompareAsUser on
            Require ldap-group cn=sprinklers,cn=groups,cn=accounts,dc=penurio,dc=us
        </If>
        ProxyPass http://172.31.252.3 timeout=1200
        ProxyPassReverse http://172.31.252.3
        # The OpenSprinkler controller sets Access-Control-Allow-Origin: *
        # but that won't work with authentication, so remove that header and
        # just copy the Origin from the request into the ACAO header
        Header onsuccess unset Access-Control-Allow-Origin
        SetEnvIf Origin "(.+)" ORIGIN=$1
        Header always set Access-Control-Allow-Origin %{ORIGIN}e env=ORIGIN
        Header always set Access-Control-Allow-Credentials: true
        Header always set Access-Control-Allow-Headers: Authorization
    </LocationMatch>
</VirtualHost>

Note that the OpenSprinkler controller is exposed at https://sprinklers.penurio.us/, and the web app is at https://sprinklers.penurio.us/ui/. (The LocationMatch directive in the configuration makes it act as a reverse proxy for any path except /ui/....) Thus, there shouldn't be any CORS issues when using a browser, as everything is being served from https://sprinklers.penurio.us.

AFAICT, this configuration works just fine with both Google Chrome and the Android app. (The Android app does require proper CORS headers, because the web app content is built in, rather than being served from https://sprinklers.penurio.us. It uses http://localhost as its Origin, which appears to be standard for Apache Cordova on Android.)

With Firefox, this configuration only mostly works. Whether the problem occurs or not seems to depend on how the web app is first accessed.

• If the web app is first accessed via the controller's built-in HTML page (https://sprinklers.penurio.us/ in my configuration), the problem will occur, and the web app will continually crash and reload.

  ("Built-in HTML page" refers to the HTML page returned by the controller in response to a request for its root path — i.e. curl http://${OS_IP}/.)

• If the web app is first accessed via the web app's /index.html (https://sprinklers.penurio.us/ui/index.html in my configuration), then the the controller can be manually added and accessed. Furthermore, subsequent access via the "built-in HTML page" will also work.

In other words, I can reproduce the problem in Firefox with the following steps.

1. Delete all saved data, credentials, cookies, etc. for https://sprinklers.penurio.us.
2. Connect to https://sprinklers.penurio.us/.
3. Watch the web app crash and reload.

OTOH, I can workaround the issue as follows.

1. Delete all saved data, credentials, cookies, etc. for https://sprinklers.penurio.us.
2. Connect to the web app at https://sprinklers.penurio.us/ui/index.html.
3. Choose Manually Add Device.
4. In the New Device pop-up:
   • Open Sprinkler Name: Home
   • Connection Type: Direct
   • Open Sprinkler IP: sprinklers.penurio.us
   • Open Sprinkler Password: (blank)
   • Save Password: (not selected)
   • Advanced
     • Use SSL: selected
     • Use Auth: selected
   • Click Submit
5. In the New Device: Authorization Required pop-up, enter my Username and Password and click Submit.
6. The web app successfully connects to my controller.
7. I can now successfully connect "directly" to the web app at https://sprinklers/penurio.us/.

In addition to the above, I may have finally been able to capture some useful information about the DOMException. (I've previously had no luck getting the Firefox debugger to tell me anything useful about it.)

I captured this screenshot that shows something that a least vaguely resembles a backtrace.

And here is the text version.

Uncaught (in promise) DOMException: The operation is insecure.                         home.js:196
    interval                        https://sprinklers.penurio.us/ui/js/home.js:196
    setInterval handler*finishInit  https://sprinklers.penurio.us/ui/js/home.js:195
    savePassword                    https://sprinklers.penurio.us/ui/js/home.js:227
    init                            https://sprinklers.penurio.us/ui/js/home.js:267
    <anonymous>                     https://sprinklers.penurio.us/ui/js/home.js:141
    insertScript                    https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>                     https://sprinklers.penurio.us/ui/js/home.js:137
    insertScript                    https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>                     https://sprinklers.penurio.us/ui/js/home.js:134
    insertScript                    https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>                     https://sprinklers.penurio.us/ui/js/home.js:131
    <anonymous>                     https://sprinklers.penurio.us/ui/js/home.js:388

    enter             resource://devtools/server/actors/utils/event-loop.js:82
    _pauseAndRespond  resource://devtools/server/actors/thread.js:984
    onEnterFrame      resource://devtools/server/actors/thread.js:1664
    interval          https://sprinklers.penurio.us/ui/js/home.js:196
    (Async: setInterval handler)
    finishInit        https://sprinklers.penurio.us/ui/js/home.js:195
    savePassword      https://sprinklers.penurio.us/ui/js/home.js:227
    init              https://sprinklers.penurio.us/ui/js/home.js:267
    <anonymous>       https://sprinklers.penurio.us/ui/js/home.js:141
    (Async: EventListener.handleEvent)
    insertScript      https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>       https://sprinklers.penurio.us/ui/js/home.js:137
    (Async: EventListener.handleEvent)
    insertScript      https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>       https://sprinklers.penurio.us/ui/js/home.js:134
    (Async: EventListener.handleEvent)
    insertScript      https://sprinklers.penurio.us/ui/js/home.js:85
    <anonymous>       https://sprinklers.penurio.us/ui/js/home.js:131
    <anonymous>       https://sprinklers.penurio.us/ui/js/home.js:388

Hopefully this is enough info to track down what is causing the exception.

[ipilcher]

Upon further investigation, I believe that I have found the cause of this issue.

My current Apache configuration looks like this.

<VirtualHost 172.31.255.2:443>
    ServerName sprinklers.penurio.us
    DocumentRoot /var/www/opensprinkler/ui
    RedirectMatch temp "^/$" "/api/"
    ErrorLog /etc/httpd/logs/sprinklers_error.log
    TransferLog /etc/httpd/logs/sprinklers_access.log
    LogLevel info
    SSLEngine on
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder on
    SSLCipherSuite PROFILE=SYSTEM
    SSLProxyCipherSuite PROFILE=SYSTEM
    SSLCertificateFile /etc/pki/tls/certs/sprinklers.penurio.us.crt
    SSLCertificateKeyFile /etc/pki/tls/private/sprinklers.penurio.us/sprinklers.penurio.us.key
    <Location "/api/">
        # OPTIONS requests must succeed (return 200 or 204) for CORS to work,
        # so don't require authentication for those requests
        <If "%{REQUEST_METHOD} != 'OPTIONS'">
            AuthType Basic
            AuthBasicProvider ldap
            AuthName OpenSprinkler
            AuthLDAPUrl ldap://127.0.0.1/cn=users,cn=accounts,dc=penurio,dc=us?uid
            AuthLDAPCompareAsUser on
            Require ldap-group cn=sprinklers,cn=groups,cn=accounts,dc=penurio,dc=us
        </If>
        ProxyPass http://172.31.252.3/ timeout=1200
        ProxyPassReverse http://172.31.252.3/
        # The OpenSprinkler controller sets Access-Control-Allow-Origin: *
        # but that won't work with authentication, so remove that header and
        # send the Origin used by the Android app
        Header onsuccess unset Access-Control-Allow-Origin
        Header always set Access-Control-Allow-Origin http://localhost
        Header always set Access-Control-Allow-Credentials: true
        Header always set Access-Control-Allow-Headers: Authorization
    </Location>
</VirtualHost>

The OpenSprinkler controller API is at https://sprinklers.penurio.us/api/, and authentication is required for anything other than OPTIONS requests). The web app content is at https://sprinklers.penurio.us/, which avoids a number of 404 errors. (The app hardcodes paths for a number of resources, although none of them appear to be critical.)

Because the controller API and the web app content are served from the same origin, CORS isn't an issue for browser-based access. The Access-Control-Allow-* headers are required by the Android app.

This configuration works with Google Chrome, Firefox, and the Android app when "app-based" basic authentication is used. By "app-based" authentication, I'm referring to the scenario in which the user first visited the web app's index.html page (or opened the Android app) and went through the Manually Add Device workflow, including specifying authentication credentials. In this case, the authentication credentials are stored in the browser/apps's local storage, and the app explicitly adds them to all API requests.

The alternative scenario is "browser-based" basic authentication. In this scenario, the user starts by directly querying the root path of the OpenSprinkler controller (http://${OS_IP}/, which is available at https://sprinklers.penurio.us/api/ in my configuration). The controller responds with a simple HTML page which runs the home.js script, from the location specified in the controller's UI Source setting.

In this scenario, the user never explicitly enters their authentication credentials into the app, and they are not saved in local storage. Thus, they are not available for the app to add them to API requests. Instead, the app relies on the browser to automatically add the correct Authorization header to its API requests.

Google Chrome is doing this, but Firefox is not.

The culprit seems to this code, at line 417 of main.js.

		// Allow cross domain AJAX requests in FireFox OS
		$.ajaxSetup( {
			xhr: function() {
				return new window.XMLHttpRequest( {
					mozSystem: true
				} );
			}
		} );

Other platforms use jQuery's standard XMLHttpRequest constructor, which does not set mozSystem: true.

I haven't been able to find too much information about the mozSystem boolean. It's definitely a non-standard Mozilla extension, and it seems like it may predate the time in which Firefox had proper CORS support. Google Gemini claims that setting mozSystem: true implicitly sets mozAnon: true, which disables sending of cookies and authentication headers. I can't find a source for this claim, but it certainly matches the behavior that I'm seeing.

After commenting out the Firefox-specific code above, Firefox is working with "browser-based" basic authentication.