PUSH - Error #401

[dl2rbi]

Zur Installation: EgroupWare 21.1.20221202 - docker-ce auf UBUNTU 22.04 LTS

Einträge im Kalender, InfoLog usw werden nach der Erstellung nicht angezeigt.
Die push Einträge im Browser Dev. Fenster zeigen Error-Code #401 (Unauthorized) an.

docker logs -f egroupware-push:
Returned for instance-token 23c39cded5938e8cc166497f94700868d1175f30 0 unique account_id’s

docker exec -it egroupware-push ls /var/lib/php/sessions
sess_4af9k9puke1bg0biarbisbt06v

docker exec -it egroupware ls /var/lib/php/sessions
sess_4af9k9puke1bg0biarbisbt06v

Push Test bringt hier ebenfalls Fehler (rot)

Wie kann ich hier den Fehler #401 (unauthorized) weiter einkreisen … ?

Grüße
Werner

[RalfBecker]

Die Ausgaben sehen ja alle Ok aus.

Hast Du Dir im Wiki das Troubleshooten und dort die Sachen zum Push mal angeschaut?

Die push Einträge im Browser Dev. Fenster zeigen Error-Code #401 (Unauthorized) an.

Was meinst Du damit?

Ralf

[dl2rbi]

Hallo Ralf,
die Einträge im WIKI habe ich soweit alle abgearbeitet - daraus auch die obigen Tests …
Error-Code #401 (Unauthorized) wird im (FireFox) Browser in den Network Dev. Tools bei jedem “push” Frame angezeigt.

scheme
wss
host
xxxxxx.de
filename
/egroupware/push
Adresse
92.xxx.xxx.xxx:443
Status
401
Unauthorized
VersionHTTP/1.1
Übertragen 230 B (0 B Größe)

HTTP/1.1 401 Unauthorized
Server: nginx
Date: Thu, 09 Feb 2023 05:34:02 GMT
Content-Type: text/html
Content-Length: 41
Connection: keep-alive
Www-Authenticate: Basic realm="EGroupware Push Server"
Content-Encoding: gzip

GET /egroupware/push HTTP/1.1
Host: xxxxi.de
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: /
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https:/xxxxx.de
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: lp+s73K7tSMfduvtPHzFbw==
Connection: keep-alive, Upgrade
Cookie: eGW_cookie_test=enabled; last_loginid=sysop; last_domain=default; sessionid=7bench7uo6kh7d0ial0b18bkov; kp3=RyF5N1rXA1Pd3MNHZdbbvfWi; domain=default
Sec-Fetch-Dest: websocket
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Es sieht so aus, als würde irgend etwas mit dem Token nicht überein stimmen ,

ADMIN -> Test Push bringt rotes Popup Fenster

Push::onlyFallback()=false --> Using native Swoole Push

SwoolPush\Backend::failedAttempts()=0, SwoolePush\Backend::backoffTime=60

SwoolePush\Backend->online()=

Push::onlyFallback()=false --> Using native Swoole Push

SwoolPush\Backend::failedAttempts()=0, SwoolePush\Backend::backoffTime=60

Push->online()=

Ein neu angelegter (oder verschobener) Kalendereintrag ist nur in der Listenansicht oder nach Logout/Login in den weiteren Ansichten sichtbar.

Grüße
Werner

[RalfBecker]

Hallo Werner,

das Token liegt in einem Docker Volumen (egroupware-docker_push) das im egroupware und egroupware-push Container gemounted ist, sprich das kann schlecht unterschiedlich sein.

Die Form könnte falsch sein, bitte NICHT Dein Token hier posten:

docker exec -it egroupware cat /usr/share/egroupware/swoolepush/config.inc.php
<?php
$bearer_token = 'xxxx 24 Zeichen xxxx';

Sollte mit dem aus dem Push Container identisch sein:

docker exec -it egroupware-push cat /var/www/config.inc.php

Das Du im Browser beim Websocket Aufruf (NICHT Eingabe/GET Request der /egroupware/push URL selbst!) einen 401 bekommst ist sehr merkwürdig, da es dort keine Authentifizierung gibt sondern nur die Sitzung überprüft wird und die Token zum Subscriben übertragen werden.

Hast Du irgeneine Änderung am Webserver vorgenommen, einen weiteren Proxy im Einsatz ODER eine Firewall mit Websecurity (oder ähnlichem) durch die der Traffik durch läuft?

Es sieht so aus, als würde KEIN Websocket Verbindungsaufbau erfolgen, sondern ein normaler GET Request. Bei einer Sophos muss man für Websockets einen Extra Haken setzen und auch ein zusätzliche Reverse Proxy muss in der Regel Websockets unterstützen.

Entweder kennst Du Dich da jetzt mit Deiner Umgebung richtig gut aus und kannst das selbst beheben, oder wir sind hier im Forum leider am Ende, und das müsste sich unser (kostenpflichtiger) Support auf Deiner Maschine mal anschauen.

Ralf

[dl2rbi]

Hallo Ralf,
danke für Deine schnelle Unterstützung.
Wie Du schon vermutet hast, passen die Konfigurationen des Tokens überein.
Firewall (Iptables) habe ich ebenfalls (auch schon früher) testweise ausgeschaltet.
Bleibt eigentlich nur noch die Rewrite/Proxy Config als Fehlerquelle für das PUSH-Thema …
Apache-Module sind auch alle vorhanden und aktiv.
Durch Stoppen des egroupware-push containers verbessert sich die Lage etwas (push fallback).
Allerdings ist dies auch nicht die Lösung und wie ihr schon geschrieben habt, wird dies in zukünftigen Releases ggf. auch nicht mehr unterstützt. Schade, EGW 19.x läuft aktuell (ohne Websocket push) recht problemlos. Alles andere hat incl. Migration bestehender Daten soweit funktioniert.
Da ich die genauen Abläufe der push Kommunikation via Websockets nicht kenne wird das schwierig ohne Referenz-System.

Ist eigentlich folgender Eintrag normal, oder deutet dies bereits auf einen Fehler (#401) hin ?

docker logs -f egroupware-push:
Returned for instance-token 23c39cded5938e8cc166497f94700868d1175f30 0 unique account_id’s

Ggf. fehlt ja noch ein Websocket Proxy-Eintrag wie von Dir kurz erwähnt … ?

Grüße
Werner

[RalfBecker]

Ist eigentlich folgender Eintrag normal, oder deutet dies bereits auf einen Fehler (#401) hin ?

docker logs -f egroupware-push:

Returned for instance-token 23c39cded5938e8cc166497f94700868d1175f30 0 unique account_id’s

Ja und Nein, bedeutet einfach, dass sich keiner der angemeldeten Benutzer für die Nachricht abonniert hat, was für das Instanz-Token ungewöhnlich ist, außer niemand ist aktuell angemeldet.

EGW 19.x läuft aktuell (ohne Websocket push) recht problemlos

Kann es sein, das Du die Apache Konfig seit der 19.1 nicht aktualisiert hast, das würde zu dem Fehlerbild passen:

EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-21.1/egroupware-docker/apache.conf

Wenn Du den Push für entbehrlich hältst hast Du noch nicht damit gearbeitet!

Ralf

[StefanU]

Da ich die genauen Abläufe der push Kommunikation via Websockets nicht kenne wird das schwierig ohne Referenz-System.

Na dann installiere dir doch eben eines und schau dir die Konfiguration des Reverse-Proxy an. Wenn du da einen Apachen haben willst must du das aber bei der Installation angeben. Wir installierten im Standard Nginx. Aus guten Gründen…

Die Konfiguration findest du natürlich auch auf GitHub

EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-21.1/egroupware-docker/apache.conf

und hier im Forum in verschiedenen Beiträgen. Bist ja nicht der erste…

Stefan

[dl2rbi]

Hallo Ralf,

danke, EGW wurde komplett neu auf einen neuen VServer (UBUBTU 22.04 mit PLESK) installiert.
Anschliessend habe ich nur die Daten zum Testen eines anderen produktiven Servers mit UBUNTU 18.04 / EGW 19 darauf migriert. Die apache.conf stammt somit von der 21.1 Installation und enthält die entsprechenden websocket Einträge.

Werde versuchen alternativ statt apache die nginx Konfiguration zu verwenden …

Sicherlich ist die PUSH-Techni eine elegante Sache, solange dies aber hier nicht funktionieren will, ist der fallback die einzigste Alternative …

Grüße
Werner

[RalfBecker]

UBUBTU 22.04 mit PLESK

Plesk setzt selbst einen Nginx als Proxy vor Deine Installation, ist genau was ich beschrieben habe, dort musst Du WebSockets unter Einstellungen für Apache & Nginx für den Nginx Proxy folgende “Zusätzliche nginx-Anweisungen” eingetragen.

Was genau da rein müsste kann ich ohne mir das anzuschauen nicht sagen, ich habe kein Plesk System im Zugriff.

Du kannst ja einfach mal einen Kommentar (# EGroupware, # ist wichtig!) eintragen und mir den erzeugte Nginx vHost hier posten, dann kann ich mal schauen.

Ralf

[dl2rbi]

Hallo Ralf,
wenn ich den Kommentar #xxxx in “zusätzliche nginx-Anweisungen” ergänze, wird in der Datei vhost_nginx.conf (vorher leer) genau diese Zeile eingefügt. (aktuell ist noch der apache aktiv, also die Option Proxymodus angekreuzt).
Diese Datei wird innerhalb von nginx.conf der jeweiligen Domain includiert.

Du wirst ggf. die nginix.conf benötigen !?
Soll nginx weiterhin die Daten an apache weitergeben (Option Proxymodus aktiv) ?

Grüße
Werner

[dl2rbi]

Hallo Ralf,

nachdem bei der Plesk-Installation nginx sowieso mitmischt, ist es wohl am sinnvollsten, die nginx Konfiguration von EGroupware einzubinden (vhost_nginx.conf) und die Weiterleitung an apache zu deaktivieren.

Hier die nginx.conf der entsprechenden Domain nachdem die Weiterleitung an apache in Plesk deaktiviert wurde:

/var/www/vhosts/system/xxx.xxx.de/nginx.conf

server {
listen :443 ssl http2;

    server_name xxx.xxx.de;
    server_name www.xxx.xxx.de;
    server_name ipv4.xxx.xxx.de;

    ssl_certificate             /opt/psa/var/certificates/scf3J9sBv;
    ssl_certificate_key         /opt/psa/var/certificates/scf3J9sBv;

    error_page 400 "/error_docs/bad_request.html";
    error_page 401 "/error_docs/unauthorized.html";
    error_page 403 "/error_docs/forbidden.html";
    error_page 404 "/error_docs/not_found.html";
    error_page 500 "/error_docs/internal_server_error.html";
    error_page 405 "/error_docs/method_not_allowed.html";
    error_page 406 "/error_docs/not_acceptable.html";
    error_page 407 "/error_docs/proxy_authentication_required.html";
    error_page 412 "/error_docs/precondition_failed.html";
    error_page 414 "/error_docs/request_uri_too_long.html";
    error_page 415 "/error_docs/unsupported_media_type.html";
    error_page 501 "/error_docs/not_implemented.html";
    error_page 502 "/error_docs/bad_gateway.html";
    error_page 503 "/error_docs/maintenance.html";

    location ^~ /error_docs {
            root "/var/www/vhosts/xxx.xxx.de";
    }

    client_max_body_size 1073741824;

    # mailconfig
    location ~* ^/autodiscover/autodiscover\.xml$ {
            try_files $uri @mad;
    }
    location ~* ^(/\.well-known/autoconfig)?/mail/config\-v1\.1\.xml$ {
            try_files $uri @mad;
    }

    location  ~* ^/email\.mobileconfig$ {
            try_files $uri @mad;
    }

    location @mad {
            rewrite ^(.*)$ /mailconfig/ break;

            proxy_pass                          http://127.0.0.1:8880;
            proxy_set_header X-Host             $host;
            proxy_set_header X-Request-URI      $request_uri;
    }
    # mailconfig

    access_log "/var/www/vhosts/system/xxx.xxx.de/logs/proxy_access_ssl_log";
    error_log "/var/www/vhosts/system/xxx.xxx.de/logs/proxy_error_log";

    root "/var/www/vhosts/xxx.xxx.de/httpdocs";

    #extension sslit begin

    add_header Strict-Transport-Security "max-age=15768000" always;

    #OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    #extension sslit end

    #extension letsencrypt begin
    location ^~ /.well-known/acme-challenge/ {
            root /var/www/vhosts/default/htdocs;

            types { }
            default_type text/plain;

            satisfy any;
            auth_basic off;
            allow all;

            location ~ ^/\.well-known/acme-challenge.*/\. {
                    deny all;
            }
    }
    #extension letsencrypt end

    location ~ /\.ht {
            deny all;
    }

    location ~ ^/(plesk-stat|awstats-icon|webstat|webstat-ssl|ftpstat|anon_ftpstat) {
            auth_basic "Domainstatistiken";
            auth_basic_user_file "/var/www/vhosts/system/xxx.xxx.de/pd/d..httpdocs@plesk-stat";
            autoindex on;

            location ~ ^/plesk-stat(.*) {
                    alias /var/www/vhosts/system/xxx.xxx.de/statistics/$1;
            }

            location ~ ^/awstats-icon(.*) {
                    alias /usr/share/awstats/icon/$1;
            }

            location ~ ^/(.*) {
                    alias /var/www/vhosts/system/xxx.xxx.de/statistics/$1;
            }
    }

    location ~ ^/~(.+?)(/.*?\.php)(/.*)?$ {
            alias /var/www/vhosts/xxx.xxx.de/web_users/$1/$2;
            fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
            try_files $uri $fastcgi_script_name =404;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_pass "unix:/var/www/vhosts/system/xxx.xxx.de/php-fpm.sock";
            include /etc/nginx/fastcgi.conf;

    }

    location ~ \.php(/.*)?$ {
            fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
            try_files $uri $fastcgi_script_name =404;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_pass "unix:/var/www/vhosts/system/xxx.xxx.de/php-fpm.sock";
            include /etc/nginx/fastcgi.conf;

    }

    index "index.php" "index.html" "index.cgi" "index.pl" "index.xhtml" "index.htm" "index.shtml";

    add_header X-Powered-By PleskLin;

    include "/var/www/vhosts/system/xxx.xxx.de/conf/vhost_nginx.conf";

}

server {
listen :80;

    server_name xxx.xxx.de;
    server_name www.xxx.xxx.de;
    server_name ipv4.xxx.xxx.de;

    error_page 400 "/error_docs/bad_request.html";
    error_page 401 "/error_docs/unauthorized.html";
    error_page 403 "/error_docs/forbidden.html";
    error_page 404 "/error_docs/not_found.html";
    error_page 500 "/error_docs/internal_server_error.html";
    error_page 405 "/error_docs/method_not_allowed.html";
    error_page 406 "/error_docs/not_acceptable.html";
    error_page 407 "/error_docs/proxy_authentication_required.html";
    error_page 412 "/error_docs/precondition_failed.html";
    error_page 414 "/error_docs/request_uri_too_long.html";
    error_page 415 "/error_docs/unsupported_media_type.html";
    error_page 501 "/error_docs/not_implemented.html";
    error_page 502 "/error_docs/bad_gateway.html";
    error_page 503 "/error_docs/maintenance.html";

    location ^~ /error_docs {
            root "/var/www/vhosts/xxx.xxx.de";
    }

    client_max_body_size 1073741824;

    # mailconfig
    location ~* ^/autodiscover/autodiscover\.xml$ {
            try_files $uri @mad;
    }
    location ~* ^(/\.well-known/autoconfig)?/mail/config\-v1\.1\.xml$ {
            try_files $uri @mad;
    }

    location  ~* ^/email\.mobileconfig$ {
            try_files $uri @mad;
    }

    location @mad {
            rewrite ^(.*)$ /mailconfig/ break;

            proxy_pass                          http://127.0.0.1:8880;
            proxy_set_header X-Host             $host;
            proxy_set_header X-Request-URI      $request_uri;
    }
    # mailconfig

    access_log "/var/www/vhosts/system/xxx.xxx.de/logs/proxy_access_log";
    error_log "/var/www/vhosts/system/xxx.xxx.de/logs/proxy_error_log";

    location / {
            return 301 https://$host$request_uri;
    }

Hier sieht Du auch die Stelle, wo die (noch leere) vhost_nginx.conf includiert wird.

include “/var/www/vhosts/system/xxx.xxx.de/conf/vhost_nginx.conf”;

Die seitens EGroupware bereit gestellte nginx.conf müsste dann noch entsprechend angepasst werden, da die Einträge ja bicht mehr zentral im /etc/nginx liegen …

Grüße
Werner

[RalfBecker]

Klar kannst auch in den Nginx vHost vom Plesk die entsprechenden EGroupware Sachen (/etc/egroupware-docker/nginx.conf) einbauen.

Ralf