Anhänge in Tickets generell nicht verfügbar + Session-Problem?

[trisse]

Hi!

Kurz meine Rahmenbedingungen:
OTRS 6.0.28 auf Apache2 unter Debian 8.0

Ich habe seit einiger Zeit das Problem, dass Ticket-Anhänge nicht mehr mitgenommen werden.
Wenn ein Kunde ein Ticket übers webinterface verfasst und dort einen Anhang hochlädt, sieht alles gut aus.
Der Anhnag wird hochgeladen und es erscheint kein Fehler oder ähnliches.

Wird das Ticket nun abgesendet, ist der Anhang in deinem Ticket einfach nicht da.
Als Agent kann ich den Anhang ebenfalls nicht sehen.
Wenn ich als Agent einen Anhang in ein Ticket packe, passiert das selbe.

Was ich allerdings seltsam finde, und ggf. auf einen Fehler hindeutet, ist, dass der Anhnag nicht vollständig aussieht:


Hier ist zu sehen, dass die Dateigröße Fehlt und das Löschen-Symbol.
Ich denke, dass das nicht normal ist.
Ich habe zugriff auf ein älteres OTRS eine anderen Kunden - dort ist das Verhalten wie erwartet:
Dateigröße wird nach dem Upload angezeigt und das Löschen-Symbol ist da.

Anhänge in meinem Mailing-System funktionieren aber generell, denn wenn der Kunde ein Ticket erstellt,
indem er eine Mail an meine ticket-system-mailadresse sendet (mit Anhang), klappt es - der Anhang ist da.

Es sieht so aus, als läge der Fehler im Webinterface.
Obwohl der Anhang (drag&drop) aktzeptiert wird, wird dieser (vmtl.) nie korrekt hochgeladen o.ä.

Da das ganze vmtl. mit JS gemacht ist, habe ich javascript im Verdacht,
denn vmtl. zusammenhängend ist folgender weiterer Fehler im Webinterface:

Öffnet der Kunde sein eigenes Ticket sieht erstmal alles gut aus:


Klickt man aber nun auf die vorherigen Beiträge erscheint über alles das hier:


Es ist zu sehen, dass nicht der Ticket-Inhalt angezeigt wird, sondern dort wird eigentlich die Anmelde-Seite in dem Fenster geladen,
mit einer JavaScript-Fehlermeldung..
Nur der letzte Artikel wird geladen, alle davor nicht.
Das Problem habe ich aber nicht im Agent-Interface - nur beim Kunden. (../cutsomer.pl)
Es liegt auch nicht am Browser, da ich mehrere Anschlüsse, Geräte und Browser ausprobiert habe.

Ich denke, dass das so nicht sein sollte, denn was mir auch aufgefallen ist, was villeicht bei der Fehlersuche hilft:
Wenn ich im Agent-Interface angemeldet bin und dann in einem neuen Tab das Agent-Interface erneut aufrufe, will er dort keine Anmeldung haben,
da ich ja bereits eine Session im System habe. Ich sehe das als logisch und gewünscht an.

Wenn ich allerdings das selbe im Customer-Interface mache, will er bei jedem Tab wieder eine Anmeldung haben.
Ist das normal oder deutet das auf einen Fehler hin?
Müsste eigentlich mit dem javascript-fehler zusammenhängen, denn ich kann im firefox debugger sehen,
dass er dort, wo die Artikel sein müssten beim aufklappen iframes lädt, die aber nicht korrekterweise den Artikel laden, sondern eben die Anmeldemaske..

Wäre echt super, wenn da mal jemand was zu sagen könnte..


Gruß!

[root]

Hi,

was ist denn die aktuelle Einstellung von der SysConfig Ticket::Article::Backend::MIMEBase::ArticleStorage ?

- Roy

[jojo]

wie ist denn der HttpType eingestellt? Und wie greifst Du auf das Kundenfrontend zu (http oder https)?

[trisse]

Hi,

was ist denn die aktuelle Einstellung von der SysConfig Ticket::Article::Backend::MIMEBase::ArticleStorage ?

- Roy

Hi!
Der Wert steht auf "Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB".

wie ist denn der HttpType eingestellt? Und wie greifst Du auf das Kundenfrontend zu (http oder https)?

Der Wert steht auf "http".
Korrekterweise, da ich das ticket-system aktuell komplett auf http ansteuere..
(wird mal geändert, aber aktuell nicht geplant)

[jojo]

dann noch eine weitere Frage, ist der FQDN im System der gleiche wie der benutzte für den Zugriff auf das Kundenfrontend?

[trisse]

dann noch eine weitere Frage, ist der FQDN im System der gleiche wie der benutzte für den Zugriff auf das Kundenfrontend?

Ja, der dort eingetragene FQDN ist auch wirklich der, über den ich und die Kunden das OTRS ansteuern.
http://<fqdn>/otrs/index.pl
und
http://<fqdn>/otrs/customer.pl

Das ist eine bestimmt 8 Jahre alte OTRS-Instalation, die bisher auch immer ganz gut funktioniert hatte.
Das Problem trat vmtl. nach irgendeinem Update auf, ich kann das aber nicht mehr zurückverfolgen.
Es sollte mit irgendeiner 6.x Version gekommen sein.
Allerdings hab ich auch keine seltsamen Veränderungen vorgenommen, die dafür verantwortlich sein könnten.

Hier einfach mal meine Config.pm - nix seltsames drin..

Code: Select all

# --
# Copyright (C) 2001-2016 xxx, http://otrs.com/
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --
#  Note:
#
#  -->> Most OTRS configuration should be done via the OTRS web interface
#       and the SysConfig. Only for some configuration, such as database
#       credentials and customer data source changes, you should edit this
#       file. For changes do customer data sources you can copy the definitions
#       from Kernel/Config/Defaults.pm and paste them in this file.
#       Config.pm will not be overwritten when updating OTRS.
# --

package Kernel::Config;

use strict;
use warnings;
use utf8;

sub Load {
    my $Self = shift;

    # ---------------------------------------------------- #
    # database settings                                    #
    # ---------------------------------------------------- #

    # The database host
    $Self->{DatabaseHost} = '127.0.0.1';

    # The database name
    $Self->{Database} = 'otrs';

    # The database user
    $Self->{DatabaseUser} = 'otrs';
	
    # The password of database user. You also can use bin/otrs.Console.pl Maint::Database::PasswordCrypt
    # for crypted passwords
    $Self->{DatabasePw} = 'xxxx';

    # The database DSN for MySQL ==> more: "perldoc DBD::mysql"
    $Self->{DatabaseDSN} = "DBI:mysql:database=$Self->{Database};host=$Self->{DatabaseHost};";

    # The database DSN for PostgreSQL ==> more: "perldoc DBD::Pg"
    # if you want to use a local socket connection
#    $Self->{DatabaseDSN} = "DBI:Pg:dbname=$Self->{Database};";
    # if you want to use a TCP/IP connection
#    $Self->{DatabaseDSN} = "DBI:Pg:dbname=$Self->{Database};host=$Self->{DatabaseHost};";

    # The database DSN for Microsoft SQL Server - only supported if OTRS is
    # installed on Windows as well
#    $Self->{DatabaseDSN} = "DBI:ODBC:driver={SQL Server};Database=$Self->{Database};Server=$Self->{DatabaseHost},1433";

    # The database DSN for Oracle ==> more: "perldoc DBD::oracle"
#    $Self->{DatabaseDSN} = "DBI:Oracle://$Self->{DatabaseHost}:1521/$Self->{Database}";
#
#    $ENV{ORACLE_HOME}     = '/path/to/your/oracle';
#    $ENV{NLS_DATE_FORMAT} = 'YYYY-MM-DD HH24:MI:SS';
#    $ENV{NLS_LANG}        = 'AMERICAN_AMERICA.AL32UTF8';
delete $Self->{"Daemon::SchedulerCronTaskManager::Task"}->{"OTRSBusinessAvailabilityCheck"};
delete $Self->{"Daemon::SchedulerCronTaskManager::Task"}->{"OTRSBusinessEntitlementCheck"};
$Self->{'DefaultCharset'} = 'utf-8';
# $self->{Debug} = 3;

    # ---------------------------------------------------- #
    # fs root directory
    # ---------------------------------------------------- #
    $Self->{Home} = '/opt/otrs';

    # ---------------------------------------------------- #
    # insert your own config settings "here"               #
    # config settings taken from Kernel/Config/Defaults.pm #
    # ---------------------------------------------------- #
    # $Self->{SessionUseCookie} = 0;
    # $Self->{CheckMXRecord} = 0;

    # ---------------------------------------------------- #

    # ---------------------------------------------------- #
    # data inserted by installer                           #
    # ---------------------------------------------------- #
    # $DIBI$

    # ---------------------------------------------------- #
    # ---------------------------------------------------- #
    #                                                      #
    # end of your own config options!!!                    #
    #                                                      #
    # ---------------------------------------------------- #
    # ---------------------------------------------------- #
	
	return 1;
}

# ---------------------------------------------------- #
# needed system stuff (don't edit this)                #
# ---------------------------------------------------- #

use Kernel::Config::Defaults; # import Translatable()
use base qw(Kernel::Config::Defaults);


# -----------------------------------------------------#

1;

Hier eine Ausgabe von otrs/bin/otrs.CheckModules.pl - auch alles i.O.

Code: Select all

  o Apache::DBI......................ok (v1.12)
  o Apache2::Reload..................ok (v0.13)
  o Archive::Tar.....................ok (v2.26)
  o Archive::Zip.....................ok (v1.60)
  o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
  o Date::Format.....................ok (v2.24)
  o DateTime.........................ok (v1.12)
    o DateTime::TimeZone.............ok (v2.39)
  o DBI..............................ok (v1.631)
  o DBD::mysql.......................ok (v4.028)
  o DBD::ODBC........................ok (v1.50)
  o DBD::Oracle......................Not installed! (optional - Required to connect to a Oracle database.)
  o DBD::Pg..........................ok (v3.4.2)
  o Digest::SHA......................ok (v5.88)
  o Encode::HanExtra.................ok (v0.23)
  o IO::Socket::SSL..................ok (v2.068)
  o JSON::XS.........................ok (v2.34)
  o List::Util::XS...................ok (v1.38)
  o LWP::UserAgent...................ok (v6.26)
  o Mail::IMAPClient.................ok (v3.39)
    o IO::Socket::SSL................ok (v2.068)
    o Authen::SASL...................ok (v2.16)
    o Authen::NTLM...................Not installed! To install, you can use: 'apt-get install -y libauthen-ntlm-perl'. (optional - Required for NTLM authentication mechanism in IMAP connections.)
  o ModPerl::Util....................ok (v2.000009)
  o Net::DNS.........................ok (v1.15)
  o Net::LDAP........................ok (v0.64)
  o Net::SMTP........................ok (v3.11)
  o Template.........................ok (v2.24)
  o Template::Stash::XS..............ok (undef)
  o Text::CSV_XS.....................ok (v1.11)
  o Time::HiRes......................ok (v1.9726)
  o XML::LibXML......................ok (v2.0116)
  o XML::LibXSLT.....................ok (v1.92)
  o XML::Parser......................ok (v2.41)
  o YAML::XS.........................ok (v0.41)

Ich hab auch schon einiges per otrs.Console.pl ausprobiert..
Maint::Config::Rebuild, Maint::Database::Check, Maint::Loader::CacheCleanup, Maint::Cache::Delete, Maint::Loader::CacheGenerate, Maint::WebUploadCache::Cleanup
Leider ohne eine Veränderung.

Ich habe auch mal den "Frontend::DebugMode" und den "Frontend::AjaxDebug" akiviert und auf eventuell aufschlussreiche Logs gehofft.
Allerdings bleibt das Log quasi unverändert. (steht nix wildes dazu drin..)


Gruß!

[zzz]

Gruß,

was sagt denn die Entwickler-Konsole Deines Browsers im Kundenbereich?
Was sagen die OTRS- und Webserver-Logs?

Probier auch noch einmal den Permission-Script durchlaufen zu lassen.

Viele Grüße
Emin

[trisse]

Das otrs.SetPermissions.pl Script lasse ich nach jedem Update durchlaufen.
Auch jetzt - ohne Erfolg.

Webserver und otrs-log ist bzgl. deem Fehler nicht aussagekräftig.
Es werden jweils keine neuen Einträge erzeugt, wenn ich den Fehler Provoziere.
Da es vmtl. irgendwie geartet javascript-mäßig ein Problem gibt, laufen Fehlerhafte Prozesse ja auch eher auch client-seite (Browser) ab.

Meine Browser-Konsole bringt mich hier vmtl. auch nicht weiter.

Rufe ich das customer-frondend auf, zeigt mir der debugger diese warnung an:

Code: Select all

Das Cookie “OTRSBrowserHasCookie” wird in Zukunft bald abgelehnt werden, da es für das Attribut "sameSite" entweder "none" oder einen ungültigen Wert angibt, ohne das "secure"-Attribut zu verwenden. Weitere Informationen zum "sameSite"-Attribut finden Sie unter https://developer.mozilla.org/docs/Web/HTTP/Cookies

Ich denke aber nicht, dass das ursächlich ist.
Ich kann sehen, dass ORTS den Cookie "OTRSCustomerInterface" erfolgreich setzt.

Leider kann ich nirgends im Debugger sehen, dass irgendetwas schief läuft, wenn ich den Fehler Provoziere.
(Anhang hinzufüge oder bestehende Tickets/Artikel öffne)

Gruß!

[zzz]

Dass das Problem mit einem Minor-Update kam, halte ich für eher unwahrscheinlich, da Du der erste mir bekannte Fall bist und weil sich seit Jahren fast nichts mehr im Kundenbereich geändert hat (ausgenommen 7+).

Ich würde auf eine Webserver Einstellung/Header tippen.
Beim öffnen eines weiteren Artikels wird eine GET-Anfrage an "[...]customer.pl?Action=CustomerTicketArticleContent[...]" gesendet.
Es sollte geprüft werden, aufgrund welcher Policy die Cookies nicht gesendet/angenommen werden.

Ich würde aber einen raschen Umstieg auf HTTPS empfehlen.
Das löst nicht nur viele Probleme, sondern wird – mittlerweile/glücklicherweise – standardmäßig von den meisten Technologien (und Anwendern) erwartet.
Ich würde mich nicht wundern, wenn es auch das Problem lösen würde.

— Emin

[trisse]

Danke!

Der tip die requests zu überprüfen war schonmal wertvoll!

Öffne ich ein Ticket wird z.B. diese GET-Anfrage gesendet.

Code: Select all

http://<fqdn>/otrs/customer.pl?Action=CustomerTicketArticleContent;TicketID=1867;ArticleID=8933;&OTRSCustomerInterface=I2vWs7cituvGxg12jUrZG6oFlbGU41cp

Das war erfolgreich, denn der content wird mir ja angezeigt.

Öffne ich den zweiten Artikel aus dem Ticket (oder jeden weiteren), wird diese Anfrage erstellt:

Code: Select all

http://<fqdn>/otrs/customer.pl?Action=CustomerTicketArticleContent;TicketID=1867;ArticleID=8926;;

Man sieht hier, dass der Parameter

Code: Select all

&OTRSCustomerInterface=I2vWs7cituvGxg12jUrZG6oFlbGU41cp

fehlt!
Füge ich diesen quasi manuell hinzu, klappt die Anfrage wieder.
Das ist auch der Wert des Cookies "OTRSCustomerInterface".

Allerdings stellt sich mir nun die Frage, warum das der Fall ist.
Klar könnte mans mal mit hhtps probieren, allerdings bleibt das Problem weiterhin unklar..

Danke für die Mühe erstmal!