omg, wegen so etwas

jetzt klappt es auch bei mir

XD

so schaut die Mail aus (DKIM nach dem Received Teil habe ich entfernt)

From sender@domain.tld  Sun Feb 10 21:14:35 2019
Received: from somepc (unknown [#IP#])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mailserver.domain.tld (Postfix) with ESMTPSA id C9BB0100AF9
	for <recipient@domain.tld>; Sun, 10 Feb 2019 21:14:35 +0100 (CET)

Message-ID: <somelettersandnumbers@domain.tld>
Subject: Test
From: "domain.tld" <sender@domain.tld>
To: recipient@domain.tld
Date: Sun, 10 Feb 2019 21:14:34 +0100
Content-Type: text/plain
User-Agent: xxx
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Test

 

 okay, also es kommt ein korrekte mal da an - dann schau doch mal ob du an die direkte URL (ohne rewrite gedöns) posten kannst und er tut was er tun soll

also soll ich direkt an eine, nennen wir sie "pipe.php", Datei posten und die url dahingehend ändern?

Ja, die URL http://myurl.tld/api/tickets.email geht ja nur das rewrite und wird ja auf irgendwas aufgelöst , z.B. http://myurl.tld/api/http.php/tickets.email (k.A. ob ich da jetzt richtig liege, rewriterules ausm kopf auflösen sind jetzt auch nich so mein ding :P)

Quote

cannot open input

sagt er mir jetzt in einer MAILER-DAEMON Nachricht

dann war meine auflösung vllt nicht ganz korrekt...k.A. scchau mal wie die http.php liegt und was die so als input haben will (parameter oder so)

ok, also ich glaube das war ein 200 Status

Quote

"POST /api/pipe.php HTTP/1.1" 200 275 "-" "Ticket API Client"

heißt das dann es es liegt ein Fehler in der Ticket-Software?

naja, das heisst erstmal nunr das der webserver api/pipe.php gefunden hat und die ausführung keinen internen fehler ausgeworfen hat....garantiert natürlich nich das das ding exakt das gemacht hat was es soll. Ich kenn halt das script nich und das projekt was da dahintersteckt was du einsetzt, daher ist hier hilfe eher schwierig

https://github.com/osTicket/osTicket/tree/develop/api

Laut htaccess geht er ja auf http.php und nicht auf pipe.php...das scheint aber in deinem fall (lokal) korrekt zu sein, allerdings nur wenn du nicht via URL zugreifst, probier doch mal  an /pfad/zu/osTicket/api/pipe.php weiterzuleiten

Allerdings ist das zeug da alles JAHRE alt...ich bin nicht sicher in wieweit das halt mit modernem PHP noch tut....ich seh da echt altes zeug...(z.B. funktions-deklarationen ohne sichtbarkeit etc.)

ehm, mein Fall ist aber remote, also ich komme von einem externen Mailserver der die Mail wie hier in diesem Thema beschrieben an die automail.php (https://github.com/osTicket/osTicket/blob/develop/setup/scripts/automail.php) weiterleitet und die automail.php sollte dann eigentlich alles erledigen. Scheint ja nicht so ganz zu klappen bisher

Also soll ich in Froxlor eine Weiterleitung von http.php nach pipe.php machen oder wie meintest du?

Just now, Afox said:

Also soll ich in Froxlor eine Weiterleitung von http.php nach pipe.php machen oder wie meintest du?

Nein natürlich nicht - das eine ist für den aufruf via HTTP protokoll, das andere via Shell...du willst als auf http.php POST'en und nicht auf pipe.php

Vllt fragst du da aber dann besser mal in osTicket foren ... das wird hier langsam sehr speziell und der Fehler liegt dabei nicht bei froxlor

ja I know, wollte dich auch eigentlich nicht im Detail damit belasten.

wenn ich an die http.php gehe kommt halt ein 400 Status

400 -> Bad Request - da scheint ihm halt was nicht zu passen, vllt fehlt ein bestimmter header oder sonstwas, k.A. - das müssten die osTicket jungs besser wissen

ok, danke dir vielmals

sorry dass ich nochmal schreibe aber ich komme einfach nicht weiter.

Ich glaube das Hauptproblem ist, dass beim Aufruf von

Quote

/api/tickets.email

ein 404 zurückgegeben wird, was ja wiederum bedeutet dass die rewrite Regel nicht angewendet wird(?), die ja eigentlich auf http.php weiterleiten müsste.

Ich habe gecheckt ob mod_rewrite aktiviert ist (ja, ist es), die RewriteEngine wird ja eigentlich durch die htaccess aktiviert und nun weiß ich einfach nicht mehr woran es noch liegen könnte.

In meiner hilflosen Unwissenheit habe ich noch testweise  allow_url_fopen aktiviert, Vermutungen in Richtung php-fpm und/oder den Dateirechten angestellt (steht nun alles in dem api-Ordner auf 777 bis auf die htaccess) oder vermutet dass es an dem Unterschied POSTender Nutzer (33) zu empfangender-Webspace-Nutzer (über 10000) liegt. Zu Letzterem und php-fpm habe ich aber keine Änderungen durchgeführt weil ich auch nicht genau weiß wie bzw. ob das wirklich ein Problem sein kann.

404 hat nichts mit lese-berechtigung zu tun, dann würdest du einen 403 kriegen.

Wie sieht denn die .htaccess bzw. die rewrite-regel aus?

Quote

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.*/api)

RewriteRule ^(.*)$ %1/http.php/$1 [L]

</IfModule>

Das Ticketsystem liegt im root Ordner von "customer". Der Aufruf der API wäre dann so http://customerurl.tld/api

Hast du denn entsprechende Leute bei osTicket mal gefragt? Wo liegt diese .htaccess? Im docroot oder in /api/ ?

Im zweifel aktivier halt mal rewrite logging/debugging das du siehst was matched und was nicht

ja der hat es bei sich probiert und meint es würde funktionieren. Die htaccess liegt in /api/.