Support » Allgemeine Fragen » Jetpack Fehlercode -10520

  • Gelöst diggaciao

    (@diggaciao)


    Hallo miteinander,

    ich wusste nun nicht ob ich ein neues Thema eröffne oder einfach unter ein bereits existierendes antworte und habe mich nun für ein Neues entschieden, da das Problem in dem Anderen gelöst wurde, allerdings bei mir noch nicht.

    Wie in diesem Beitrag beschrieben, bin auch ich bei Strato Kunde (DiggaCiao) und bekomme den „Fehlercode: -10520“ sobald ich versuche die „Publizice“-Funktion mit Facebook zu verbinden.

    Allerdings hat bei mir nicht einer der im Beitrag oben genannten Lösungsansätze geholfen und die Dame beschreibt auch leider nicht, wann bei ihr das „goldene Zeitalter“ anging, zu dem sie das Problem nicht mehr hatte.

    Ich weiß nun leider auch nicht was ich machen soll zumal Strato mir auch nicht antwortet. Gibt es noch weitere Ideen wie man dieses Problem angehen könnte oder hat zwischenzeitlich jemand eine detaillierte Fehlerbehebung die den Fehler direkt dingfest macht?

    Viele Grüße

Ansicht von 9 Antworten - 1 bis 9 (von insgesamt 9)
  • Hallo @diggaciao,

    ich hab dir grade geantwortet, allerdings ist der Beitrag wohl wegen der Einbindung mehrerer Links zunächst leider im Spam-Ordner gelandet. Deshalb ist er derzeit nicht sichtbar, wird aber sicherlich mit etwas Verspätung freigeschaltet.

    Hallo @diggaciao,

    ich bin immer noch der Meinung, die ich in diesem Beitrag vertreten habe.

    Es waren, wenn ich das richtig sehe, hier im Forum bisher immer Strato-Kunden, die dieses Problem, zumindest eine Zeit lang, hatten.

    Meine Theorie ist nach wie vor, dass es bei den betroffenen Websites bzw. dem betroffenen Shared-Hosting-Server verstärkt Attacken auf die XML-RPC-Schnittstelle gab und Strato in einem solchen Fall aus Sichehetsgründen eine Verzögerung der Abarbeitung auslöst, was dann zur Fehlerauslösung führt. Nach einer gewissen Zeit wird das wieder aufgehoben und es läuft wieder. Daher auch nie eine konkrete Lösungsmeldung der betroffenen User. So weit der Reim, den ich mir auf die Problematik mache. 🙂

    Ich sehe daher 4 Möglichkeiten:

    (1)
    Problem aussitzen

    (2)
    Hoster wechseln (von anderen Hostern in Deutschland noch nicht gehört)

    (3)
    IFTTT-Methode nutzen
    Ich schrieb im verlinkten Thread:

    In der Zwischenzeit könntest du mal mögliche Alternativen zu Jetpack:Publicize testen, falls du es nicht schon getan hast, zum Beispiel IFTTT:<br>
    IFTTT (1)<br>
    IFTTT (2)

    (4)
    Lösung wie beim englischen Kunden (sehr unwahrscheinlich bei Strato bzw. bei Shared-Hosting);
    Ich schrieb im verlinkten Thread:

    Zum andern habe ich eben noch einen
    Artikel
    von vor einem Jahr gefunden, in dem ein IT-ler das gleiche Problem (Jetpack und der verhinderte Zugriff auf die XML-RPC-Schnittstelle) beim britischen Webhoster Evohosting hatte und dies lösen konnte, indem er die Nutzung eines speziellen Plugins zum Schutz vor XML-RPC-Pingbacks zusagte (
    dieses
    und ein
    weiteres
    Plugin hatte ich oben auch schon verlinkt; vgl. ihre jeweilige Funktionsbeschreibung) und vom Webhoster deshalb auf die Whitelist gesetzt wurde.

    Thread-Starter diggaciao

    (@diggaciao)

    Hallo Flower33,

    deine Beiträge kannte ich bereits aus dem vorhandenen Beitrag, vielen Dank für deine hilfreichen Antworten und vor allem die schnelle Reaktion, allerdings gab es auch hier keine Lösung für mich da Strato IFTTT ebenfalls blockiert (zumindest passiert bei der Installation einfach nichts) und der Support von Strato sich einfach mal gar nicht meldet.

    Das ist äußerst ärgerlich und ich hab‘ dann mittlerweile auch einfach die Nase voll und werde wirklich den Provider wechseln. Was bleibt auch anderes übrig wenn man nicht mal eine Antwort vom „Problemverursacher“ bekommt…

    Vielen Dank nochmal 🙂

    Hallo @diggaciao,

    danke für deine Rückmeldung!
    Endlich mal ein konkretes Ergebnis am Schluss eines Jetpack-10520-Threads, wenn auch nicht das ursprünglich erhoffte. Aber ich kann deinen Entschluss gut verstehen.
    Ich wünsche dir bessere Erfahrungen beim nächsten Hoster.

    Moin @diggaciao,

    solltest Du zu uns wechseln wollen, kannst Du das Problem, wenn es auftritt, wie folgt beheben: https://www.checkdomain.de/support/faq/stoerungen/wordpress-fehler/jetpack-connection-error.php

    Auch bei den meisten anderen Hostern sollte das funktionieren. Falls jemand den Apache noch in der Version 2.2 verwendet, muss es allerdings

    
    <Files xmlrpc.php>
    Order Deny,Allow
    Allow from all
    </Files>
    

    heißen.

    Beste Grüße,
    Torge von checkdomain

    @diggaciao
    Ohne irgendeine Wertung des Wechsel- bzw. Hosting-Angebots von checkdomain vornehmen zu wollen oder zu können:

    Vor einem Wechsel sollte man immer gut rechercheiern und nichts überstürzen.
    Ich bin kein Hosting-Experte, das muss ich vorausschicken, aber ich halte den obigen Tipp von checkdomain für suboptimal, denn damit wird meines Wissens nach der Teufel mit dem Beelzebub ausgetrieben, wie man so schön sagt. 🙂

    Die XML-RPC-Schnittstelle stellt ja bekanntlicherweise auch ein interessantes Angriffsziel dar, wobei viele Sicherheitsexperten sogar empfehlen, sie eher ganz zu deaktivieren, siehe z.B. hier:

    https://www.kuketz-blog.de/wordpress-angriffe-auf-die-xmlrpc-schnittstelle-xmlrpc-php-unterbinden/

    Das bringt natürlich Probleme für bestimmte Blogger Anwendungen wie z.B. Jetpack:Pulicize.
    Nun aber aus „Deny from all“ ins andere Extrem „Allow from all“ zu verfallen bzw. von „Require all denied“ zu „Require all granted“, erscheint mir nicht unproblematisch. (Lies wirklich mal den eben verlinkten deutschsprachigen Artikel von Kuketz!)

    Somit erscheint mir persönlich der Einsatz von Plugins sinnvoller, die Zugriffe auf die XML-RPC-Schnittstelle möglichst nur von wenigen ausgewählten Seiten zulässt, z.B. von Jetpack. Ich habe selbst keine Erfahrung damit, aber schau dir mal die beiden schon von mir genannten Plugins an, die genau das eben Gesagte zu verwirklichen suchen, also z.B.

    (1)
    https://wordpress.org/plugins/disable-xml-rpc-pingback/

    Stops abuse of your site’s XML-RPC by simply removing some methods used by attackers. While you can use the rest of XML-RPC methods.
    This is more friendly than disabling totally XML-RPC, that it’s needed by some plugins and apps (I.e. Mobile apps or some Jetpack’s modules).

    oder

    (2)
    https://wordpress.org/plugins/stop-xmlrpc-attack/
    Letztgenanntes macht eigentlich genau das in deinem Fall Gewünschte:

    This WordPress plugin will block access to xmlrpc.php from everywhere, except the JetPack/Automattic’s subnets. On a regular basis, the plugin will poll ARIN and update your .htaccess to allow the subnets that belongs to AUTOM-93 (which is Automattic, Inc.).

    Dummerweise liegt die letzte Aktualisierung 2 Jahre zurück.
    Aber auch das erstgenannte Plugin klingt besser als die Lösung, die Scheunentore ganz aufzumachen. 🙂

    @checkdomain.de
    Hallo Torge,

    Der Stadtgärtner. Analytisch durchkämmt er den wilden Garten des World Wide Web und sät das Checkdomain-Saatgut an den richtigen Stellen aus.

    Lustige Jobbeschreibung auf eurer Website. 🙂
    Schön, auch mal von Hoster-Seite was zu hören. Nimm meine kritischen Worte zu dem Lösungsvorschlag bitte nicht persönlich, mir ist wirklich an einer sachlichen Diskussion gelegen und ich lasse mich fachlich gerne eines Besseren belehren. 🙂 Ich bin von dieser spezifischen Problematik nicht persönlich betroffen, aber Fakten zu ihrer Lösung interessieren mich aus technischem Interesse trotzdem sehr. Gleichzeitig ist mir aber auch der Sicherheitsaspekt ganz wichtig.
    Was hältst du von den Plugin-Lösungen?

    Moin @flower33,

    danke für deinen guten Beitrag. Wir versuchen immer Sicherheit und Einfachheit für unsere Kunden gegeneinander abzuwägen und haben den relativ rabiaten Weg, den wir in unserem FAQ beschreiben, daher so gewählt. Allerdings kannten wir die beiden PlugIns nicht. Wenn die gut funktionieren und sicher sind, dann ist das natürlich der bessere Weg, weil es auch sehr einfach und grundsätzlich natürlich deutlich sicherer ist.

    Wir werden die PlugIns diese Woche einmal ausprobieren und unseren FAQ-Artikel dann ggf. anpassen, wenn es gut funktioniert.

    Vielen Dank für den Beitrag & beste Grüße,
    Torge

    Thread-Starter diggaciao

    (@diggaciao)

    Grundsätzlich muss ich auch hinzufügen, dass mir das Herumfummeln an .htaccess ganz und gar missfällt und ich ohnehin nicht auf die Idee gekommen wären dort etwas zu ändern.

    Danke aber für den Hinweis, doch selbst wenn das die einzige Lösung für jeden Provider wäre, würde ich eher auf Jetpack verzichten als Zugänge freizugeben, die besser geschlossen bleiben 😉

    Der Provider-Wechsel ist übrigens schon im Gange. Danke nochmals für die zahlreichen Antworten!

    @checkdomain.de
    Hallo Torge,
    vielen Dank für deine Rückmeldung! Wäre natürlich super spannend, wenn du dich bei Gelegenheit hier noch mal mit ein paar Kommentaren bzgl. eurer Erfahrungen mit den genannten oder ähnlichen Plugins melden könntest. 🙂

    Hallo @diggaciao,

    Grundsätzlich muss ich auch hinzufügen, dass mir das Herumfummeln an .htaccess ganz und gar missfällt und ich ohnehin nicht auf die Idee gekommen wären dort etwas zu ändern.

    Weil das „Herumfummeln an .htaccess“ in Verbindung mit dem „Grundsätzlich“ so negativ klingt:

    Ein *grundsätzliches* Verweigern der .htaccess gegenüber ist nicht sinnvoll, weil es ein völlig legitimes und auch sehr nützliches Werkzeug ist, wenn man weiß, was man tut. Nicht zuletzt viele Sicherheitseinstellungen sind darüber zu bewerkstelligen. Je nach Kennnisstand ist natürlich vorsichtig vorzugehen (was du vermutlich auch gemeint hast), aber ich würde da an deiner Stelle keine grundsätzliche „Allergie“ entwickeln, sondern versuchen, mich nach und nach immer mehr darüber kundig zu machen, um dieses Werkzeug effektiv nutzen zu können.

    Danke aber für den Hinweis, doch selbst wenn das die einzige Lösung für jeden Provider wäre, würde ich eher auf Jetpack verzichten als Zugänge freizugeben, die besser geschlossen bleiben

    Du kannst ja mal direkt bei deinem neuen Hoster nachfragen, wie das dort geregelt ist und bei zu großzügiger Regelung aus Sicherheitsgründen die genannten Plugins testen.

Ansicht von 9 Antworten - 1 bis 9 (von insgesamt 9)
  • Das Thema „Jetpack Fehlercode -10520“ ist für neue Antworten geschlossen.