Beiträge von KB19

Das löst zwar das ursprüngliche Problem nicht, aber spricht etwas gegen einen Workaround? Statt Weiterleitung die Zustellung in ein Postfach bei netcup und in weiterer Folge der Abruf alle paar Minuten über IMAP/POP3. Das kann man mit getmail/fetchmail wunderbar automatisieren. Einige Mailanbieter bieten so ein Feature sogar direkt an.

Dass das nicht für alle Nutzer und Ziele eine Option ist, ist mir schon klar. Ich sehe Weiterleitungen aber sowieso spätestens seit SPF & DMARC als sehr problematisch an. Weiterleitungen sind eine Krücke, die langfristig gesehen immer mehr Probleme machen werden. Meiner Ansicht nach Fail by Design und damit meine ich nicht SPF/DMARC.

Zitat von MSandro

Aktuell meldest du dich mit deinem SCP Account an, hierzu muss der Sicherheitsmodus scheinbar deaktiviert sein. Das 2FA Feature gilt nur für das CCP was an sich nichts mit dem SCP zu tun hat.

Ja, weil es mit dem Sicherheitsmodus aktuell nicht klappt. Sollte aber nicht so sein laut [netcup] Lucia S.

Und wenn der Sicherheitsmodus aktiviert ist, wäre es etwas witzlos, wenn man über die App ohne 2FA in einen Teilbereich des SCP reinkommt. Vor allem da man nicht weiß, ob über die verwendete Schnittstelle nicht mehr Schaden anstellbar wäre, als einen Server abzuschalten.

Aber warten wir mal ab, wie es wirklich ist. Mit den Zugangsdaten vom CCP komme ich jedenfalls nicht rein. Und mit den alten Zugangsdaten vom SCP von vor zig Jahren (vor dem Sicherheitsmodus) auch nicht. Insofern ist derzeit alles "sicher", so wie es sein soll

Zitat von [netcup] Lucia

Hier kam es zu einem Missverständnis:

• Nein, Webservice im SCP muss NICHT aktiviert sein
• der Sicherheitsmodus im SCP muss NICHT deaktiviert sein

Wenn du dann trotzdem nicht zugreifen kannst, hätten wir einen Bug.

Bin gespannt, was du berichtest.

Mit welchen Zugangsdaten meldet man sich dann an? Mit denen vom CCP? Das SCP hat ja beim Sicherheitsmodus kein Passwort mehr.

Und erfolgt dann planmäßig eine Abfrage des 2FA-Codes? Oder umgeht die App bzw. der Serverteil dieses Sicherheitsfeature?

MSandro Gilt nur für Neukunden. Die Verknüpfung wird bei Bestandskunden nicht mehr hergestellt bzw. verändert.

Zitat von [netcup] Lucia

Einfach anmelden, durchklicken und ausprobieren

Nur zur Klarstellung, ob das nach wie vor zutrifft und kein Bug ist:

• Der Webservice muss im SCP aktiviert sein.
• Der Sicherheitsmodus muss im SCP deaktiviert sein.

Vor allem Letzteres würde derzeit verhindern, dass alle 2FA-Nutzer die App testen. Ist es geplant, das irgendwann in der Zukunft anzupassen, damit auch eine Nutzung mittels CCP-Zugangsdaten bzw. TOTP-Pin möglich ist?

(Falls das mittlerweile geht, bitte ich um Entschuldigung. Zuletzt getestet vor einigen Tagen.)

Habe ich eigentlich schon oft genug erwähnt, dass ich Python wirklich hasse?

(Der Thread nebenan hat mich nur gerade daran erinnert, dass selbst ein 5-Zeilen Patch grauenhaft zu schreiben ist.)

Hast Du Python für diese (Sub-) Domain im WCP aktiviert?

Steht irgendwas in den Errorlogs des Webservers? (Solltest Du über FTP, SSH oder im WCP sehen.)

Probiere es zum Test auch mal mit der Dateiendung cgi, siehe: https://forum.netcup.de/anwendung/wcp-…r-pl-verwenden/

Zitat von codesight

Was hat das mit meiner E-mail-Adresse zu tun, wenn ich über das Kontaktformular im CCP eine Anfrage schicke ??

Ich der Antwortmail wird mir dann auch noch vorgeschlagen, ich solle das Kontaktformular nutzen, was ich ja eben getan hatte...

Das ist mir schon klar und auch, dass das jeglicher Logik entbehrt.

Soweit ich das verstanden habe, werden Tickets durch das CCP einfach mit der derzeitigen E-Mail Adresse des Kunden erstellt. Ob über SMTP oder die API des Ticketsystems ist dabei egal, weil höchstwahrscheinlich kein direkt sichtbares CCP-Flag o.ä. gesetzt wird, da bei kritischen Aktionen normalerweise immer eine Rückfrage erfolgt. Wenn das Ticket jetzt erst später gelesen wird, stimmt die "Absenderadresse" eventuell nicht mehr überein.

Oder der Mitarbeiter hat sich bei einer manuellen Kontrolle der Kundendaten verschaut. Wie auch immer, Fehler passieren, auch wenn das Ergebnis in diesem Fall noch so absurd wirkt. Nochmals schreiben und der Fall sollte erledigt sein...

Hast Du vielleicht kürzlich Deine E-Mail Adresse im CCP geändert? Da soll das durchaus mal vorkommen, wenn sich die vollständige Übernahme der Daten und das Ticket überschneiden.

Andernfalls: Nochmals antworten oder neues Ticket eröffnen. Ist zwar unschön, aber Fehler passieren.

Zitat von tab

Das Ticket hier lasse ich offen, der Fehler ist nämlich gerade eben wieder aufgetreten

Ein Klassiker. Normalerweise passiert das aber immer erst, wenn man "OK" Rückmeldungen auf E-Mails gibt. Bei Dir hat wohl schon alleine der Gedanke gereicht

geekmonkey Tidy ist laut phpinfo() jedenfalls überall verfügbar bei mir…

for i in /usr/local/php*/bin/php; do echo -n "$i: "; "$i" -i | grep -Fo -- --with-tidy || echo; done
/usr/local/php56/bin/php: --with-tidy
/usr/local/php70/bin/php: --with-tidy
/usr/local/php71/bin/php: --with-tidy
/usr/local/php72/bin/php: --with-tidy
/usr/local/php73/bin/php: --with-tidy
/usr/local/php74/bin/php: --with-tidy

for i in /usr/local/php*/bin/php; do echo -n "$i: "; "$i" -i | grep -Fo -- --with-tidy || echo; done
/usr/local/php56/bin/php: --with-tidy
/usr/local/php70/bin/php: --with-tidy
/usr/local/php71/bin/php: --with-tidy
/usr/local/php72/bin/php: --with-tidy
/usr/local/php73/bin/php: --with-tidy
/usr/local/php74/bin/php: --with-tidy

for i in /usr/local/php*/bin/php; do echo -n "$i: "; "$i" -i | grep -Fo -- --with-tidy || echo; done
/usr/local/php54/bin/php: --with-tidy
/usr/local/php55/bin/php: --with-tidy
/usr/local/php56/bin/php: --with-tidy
/usr/local/php70/bin/php: --with-tidy
/usr/local/php71/bin/php: --with-tidy
/usr/local/php72/bin/php: --with-tidy

Oder wie äußert sich der Fehler genau?

Zitat von tab

Daraufhin habe ich ein Ticket eröffnet. Jetzt, einige Minuten später, ist der Fehler wieder verschwunden. Kann man ein Ticket irgendwie löschen/canceln/als erledigt markieren?

Leider nicht, aber Du kannst einfach noch ein Ticket eröffnen. Ist etwas unlogisch, aber afaik sieht der Support alle Tickets eines Users in der Liste und sieht sich hoffentlich das neueste zuerst an. Wähle halt einen passenden Betreff, dass es ins Auge sticht.

Zitat von twiddern

Nicht überall

Spannend. Eventuell nur bei neueren Hosts?

Bei "meinem" gibt es sogar schon DKIM.

Zitat von whoami0501

Außerdem ist der Mailserver vom Netcup Webhosting nicht über IPv6 erreichbar.

Das halte ich für ein Gerücht

Received: from ***** (***** [IPv6:2a00:1158:3::****])
    by mx2e4b.netcup.net (Postfix) with ESMTPS id EB0E31C0597
    for <test@*****>; Sun,  8 Mar 2020 08:28:40 +0100 (CET)

Als ich mich mit den DNS-Records fürs WH8000 befasst habe, habe ich auch einen AAAA-Record für "mail" hinzugefügt. Die Adresse bekommt man, wenn man den AAAA-Record von mxXXXXX.netcup.net abfragt. Dort ist nämlich recht wohl einer hinterlegt.

Kann ich nur bestätigen. Über FCGI gibt es Tidy jedenfalls bei PHP 7.3 bzw. 7.4. CLI kann ich gerade nicht testen am Handy.

Zitat von whoami0501

Funktioniert bei mir im Firefox Dev Edition unter Windows 10 ganz normal...

Danke fürs Testen. Ich bin zwischenzeitlich auch schon schlauer geworden…

Firefox kein Problem, Chromium im Inkognitomodus auch nicht. So wie es aussieht, funktioniert es nur in der normalen Chromium-Session nicht. Die Addons scheinen unschuldig zu sein, aber die Cookies dürften dazu führen, da ich auf post.at eingeloggt bin. Sobald ich die leere, funktioniert es. Wenn das in der finalen Version später auch so ist, wird die neue Website der österreichischen Post garantiert ein Erfolg!

Edit: Jup, eindeutig reproduzierbar. Sobald man auf post.at wieder eingeloggt ist, wirft preview.post.at einen 403er. Auch im Inkognitofenster.

Lustigerweise funktioniert der Login auf der neuen Website problemlos, wenn man nur die neuen Cookies hat.

Funktioniert bei Euch preview.post.at?

Über cURL kann ich darauf zugreifen, im Browser (Chromium unter Xubuntu) erhalte ich nur einen 403er vom Microsoft-Azure-Application-Gateway/v2. Am Useragent liegt es nicht, die werten irgendwas anderes aus den Headern aus. IPv6 hat das Teil nicht, daran liegt es also auch nicht…

Edit: Umfrage zur neuen Website mal "passend" ausgefüllt

Gibt es beim Webhosting irgendeine Art Ratelimit für PUT-Anfragen oder liegt das an meiner Nextcloud-Testinstallation?

Ich bastel gerade an einem kleinen Chunk-Upload-Tool und experimentiere da absichtlich mit winzigen Chunkgrößen (10 KB), weil mir dieser Fehler bei manuellen Tests mit cURL schon vom Server aus mit der Gbit-Anbindung bei 10 MB Chunks aufgefallen ist.

[2020-03-07T21:06:17+01:00] WebDAV MKCOL: nccu-5e63feb9eb4587
[2020-03-07T21:06:18+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-00000-10240 (chunk 1 of 5)
[2020-03-07T21:06:20+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-10240-20480 (chunk 2 of 5)
[2020-03-07T21:06:21+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-20480-30720 (chunk 3 of 5)
[2020-03-07T21:06:21+01:00] HTTP Error 400! Let's retry...
[2020-03-07T21:06:22+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-20480-30720 (chunk 3 of 5)
[2020-03-07T21:06:23+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-30720-40960 (chunk 4 of 5)
[2020-03-07T21:06:23+01:00] HTTP Error 400! Let's retry...
[2020-03-07T21:06:24+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-30720-40960 (chunk 4 of 5)
[2020-03-07T21:06:25+01:00] WebDAV PUT: nccu-5e63feb9eb4587/10240-40960-44218 (chunk 5 of 5)

Wenn ich den Fehler 400 abfange und die Anfrage nach einem kurzen sleep(1) nochmals stelle, klappt es immer. Habe ich das sleep(1) schon von Haus aus drinnen, gibt es keine Probleme.

Ich habe es noch nicht getestet, aber was spricht dagegen, wenn Du die Backups einfach selbst immer wieder außer Reichweite des FTP-Users kopierst/verschiebst?

Versuche einmal vorher die ganze Festplatte im SCP zu formatieren: https://www.netcup-wiki.de/wiki/Server_Co…te_l.C3.B6schen

Dadurch sollte auch die bestehende Partitionstabelle verschwinden. Funktioniert es dann?