Including "Basic authentication header" forces UI into login promt even if auth aren't explicit enabled

[EliasGabrielsson]

The problem

When sending a request which includes a basic authentication header the UI will be stuck at a login promt even if openHAB doesn't require authentication. It looks like the browser automatically got redirected to "https://openhab.site.com/rest/" when an "basic auth" header was provided in the request.

This invalidates the usecase of using openHAB behind the reverse proxy "haproxy" configured with basic authentication. This is an issue as the "basic auth header" are kept in the request after being used by haproxy.

Expected behavior

If openHAB are not configured with basic authentication the login promt are not to be shown.

Steps to reproduce

1. Add "random" basic auth header when requestning access to openHAB.
2. Access openhab

Your environment

runtimeInfo:
  version: 3.2.0
  buildString: Release Build
locale: sv-SE
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 11.0.14
  javaVendor: Raspbian
  osName: Linux
  osVersion: 5.10.92-v7l+
  osArchitecture: arm
  availableProcessors: 4
  freeMemory: 102179416
  totalMemory: 201326592
bindings:
  - mqtt
  - onewiregpio
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: true
    macos: true
    windows: false
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: macos
    pixelRatio: 2
    prefersColorScheme: light
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 2
    language: sv-SE
    languages:
      - sv-SE
      - sv
      - en-US
      - en
    onLine: true
    platform: MacIntel
  screen:
    width: 3008
    height: 1692
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: filled
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101
    Firefox/97.0
timestamp: 2022-02-19T22:50:15.478Z

[hubsif]

Hi @EliasGabrielsson, I tried to reproduce your issue, but couldn't. I just tried by running bundle:stop org.openhab.core.io.rest.auth on the console and injecting an basic auth header - works just fine. How actually did you disable authentication?

This is an issue as the "basic auth header" are kept in the request after being used by haproxy.

Also, is this a known issue? I would expect haproxy to not forward auth if auth is enabled 🤔.

[EliasGabrielsson]

Hi Hubsif! Sorry for being late to respond and thank you for looking into this.

✅ When I disabled bundle:stop org.openhab.core.io.rest.auth I didn't get a redirect to loginpromt anymore. Solved my issue, good!

❕However I still find i strange that I would be redirected to the "rest" API if I just call the web root. ie. when a) bundle:stop org.openhab.core.io.rest.auth = enabled, b) Auth header is attached and c) root URL of openhab is called I expect to just land in on the "landingpage/homescreen" with unauthorized access (similar to just visit the page). Possibly could openhab log me in if the credantial matches one account.

Is this pattern by design?

[ghys]

Could you elaborate on your setup esp. the network interactions that occur?

[EliasGabrielsson]

Hi again 👋 Giving this another go, still having issues when using latest stable 3.3.0. My setup is using opnsense (firewall distro) running HAproxy infront of openhab to enable SSL encapsulation and authentication. HAProxy is using HTTP basic auth which works flawless but somehow breaks havoc later on when the request is passed to openhab. (Disabling bundle:stop org.openhab.core.io.rest.auth kind of works as a workaround until you actually need the rest-api.)

My guess is that somehow the auth-header is kept in the call (after HAProxy) and automatically triggers openhab to show the loginpromt.

I built a simple configuration using HAProxy attached below to reproduce the error in opnsense.

What would be the next step, should I do some specific logging on the openhab side? I need some direction how to provide a better bug-report.

Kind Regards

#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    hard-stop-after             60s
    no strict-limits
    tune.ssl.default-dh-param   2048
    spread-checks               2
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 debug
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc

# autogenerated entries for ACLs

# autogenerated entries for config in backends/frontends
userlist list_634b0cde944b30.81205990
    # Origin: public.domain.se
    user test insecure-password password
    # NOTE: UserlistAddUsers called with empty group data

# autogenerated entries for stats

# Frontend: public-facing-side ()
frontend public-facing-side
    bind WAN-IP:443 name WAN-IP:443 ssl alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/634b0e00949c72.20428522.certlist 
    mode http
    option http-keep-alive
    # tuning options
    timeout client 30s

    # logging options
    # ACL: condition-public
    acl acl_634b0e47580900.62526726 hdr(host) -i public.domain.se

    # ACTION: rule-use-public
    use_backend public.domain.se if acl_634b0e47580900.62526726

# Backend: public.domain.se ()
backend public.domain.se
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m  
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    acl auth_ok http_auth(list_634b0cde944b30.81205990)
    http-request auth if !auth_ok
    http-reuse safe
    server openhab.internal.gabson.se openhab.internal.gabson.se:443 ssl alpn h2,http/1.1 verify none

[lsafelix75]

Has this been identified and resolved? The pop actually comes from app.vue