No icons shown in iOS app

Apps & Services iOS App
,
1

Hello,

I am running openhab 2 behind an ssl nginx reverse proxy with http basic auth (as described in the docs http://docs.openhab.org/configuration/nginx.html). Within the browser (classic ui as well as basic ui) all icons are working fine. When accessing openhab through the iOS app the icons run into an http 401 not authorized regarding nginx access log. Why are the authentication settings are not used while accessing the icons?

I am using app version 1.7.1 and openhab 2.0.0~b4 from linux repositories.

As a temporary workaround I have created a separate “location ^~ /icon {” block in nginx config without http basic auth.

Any ideas on this?

Thanks,
Peter

2

Very strange, I’m using pretty much those settings, and it’s working on both my android phone and my partner’s iPhone.

Could you post the contents of your file at /etc/nginx/sites-enabled/? (remember to omit your domain/IP, but tell me which method you are using) I can take a look and test using similar settings and her iPhone.

3

Thanks for your feedback, Ben!

This is my nginx site config. I have replaced my domain by DOMAIN and the ip address with IPADDRESS. The icon-part is the workaround I described above.

server {
 listen 80;
 server_name DOMAIN IPADDRESS;

 return 301                      https://$server_name$request_uri;

}

server {
 listen 443 ssl http2;
 server_name DOMAIN IPADDRESS;

 ssl on;
 ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;
 ssl_protocols TLSv1.2;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
 ssl_dhparam /etc/nginx/ssl/dhparams.pem;
 ssl_ecdh_curve secp521r1;
 ssl_prefer_server_ciphers on;
 ssl_stapling on;
 ssl_stapling_verify on;
 ssl_trusted_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
 ssl_session_timeout 24h;
 ssl_session_cache shared:SSL:50m;
 ssl_session_tickets off;
 add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
 add_header X-Content-Type-Options nosniff;
 add_header X-Frame-Options "SAMEORIGIN";
 add_header X-XSS-Protection "1; mode=block";
 add_header X-Robots-Tag none;
 add_header X-Download-Options noopen;
 add_header X-Permitted-Cross-Domain-Policies none;

 location ^~ / {
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_pass http://127.0.0.1:8080;
  proxy_buffering                       off;
  auth_basic                            "Username and Password Required";
  auth_basic_user_file                  /etc/nginx/.htpasswd;
 }

 location ^~ /icon {
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_pass http://127.0.0.1:8080;
  proxy_buffering                       off;
 }

 location ^~ /.well-known/acme-challenge {
  proxy_pass http://127.0.0.1:81;
  proxy_redirect off;
 }

}
4

My initial thoughts.

  1. Try without the ^~ and including the final / on the proxy_pass address? There’s a slight difference in how those locations will be processed. (you’ll need to remove the icon block also): e.g:
  location / {
    proxy_pass http://127.0.0.1:8080/;
    #[etc...]
}

  1. That http2 option is available for newer versions of NGINX than I can use, but I am aware that there’s some problems with mobile browsing using that setting. This also may be the case for your restriction to TLSv1.2, any reason why you’ve set that and other headers particularly the X-Permitted-Cross-Domain-Policies?

  2. Your final setup differs a lot to the suggested setup. Does it work using the “Putting it all together” configuration as suggested in the docs? I see you’re using a different method to access /.well-known/ so feel free to keep that part as it was if you’re able to certbot -renew --dry-run