Du bist nicht angemeldet.
Auf Sourceforge gehen nur mehr https Links. Das wget von der Box kann nur ftp und http, die svndownload.sh ist somit nutzlos geworden wie ich auf die Schnelle sehe.
Das ist auch nicht zu fixen, denn z.B. auf einer 7360v2 ist trotz freetz leider so eine alte Busybox ab Werk dabei.
Kann man nicht Curl statt wget dafür verwenden?
Hat Sourceforge irgendwas am Layout geändert?
Ich glaub ja.
Oder haben die technische Probleme?
Glaube nein.
Würde gerne den neuesten Trunk runterladen, aber das get weder manuell noch über die svndownload.sh.
Im Browser ging es bei mir von Hand per https://sourceforge.net/p/avmload/code/HEAD/tarball ggf. den Snapshot generieren.
Wenn man auf Freetz umsteigt geht vielleicht noch was, aber nur wegen F!L - für mich zu zeitaufwendig.
Muss man nicht im Prinzip für jeden Weg per Bootloader inzwischen gehen?
Was kann man nun tun?
AVM aufkaufen.
Eine schlankere und absolut lokale Geschichte ist pyload.
Den Docker habe ich auch kurzzeitig laufen gehabt, allerdings sieht das an der Front
ähnlich aus wie bei F!L was den Plugin-Support angeht.
Der Plugin-Support in Pyload ist schon etwas besser als in F!L. Nur bleibt JDownloader führend bei Updates bisher.
Früher hätte ich noch Plowshare (commandline) genannt aber dort ist der Plugin-Support noch schlechter inzwischen.
Welche Alternativen nutzt ihr?
Ich fürchte für eine Box ohne Desktop/GUI bleiben keine Alternativen neben JDownloader und Pyload derzeit mehr übrig.
Ich glaub Freerapid geht auch nur per Desktop trotz Java, bin mir grad unsicher. Auf dem Desktop gibt es noch TotalD, Mipony, Load und Ant Download Manager.
Ist das nur bei mir oder ist 9kw.eu schon 24h+ jetzt nur sehr schlecht, seit heute morgen gar nicht erreichbar.
9kw.eu ist online (ipv4+ipv6). Manchmal gibt es eine erhöhte Warteliste und damit höhere Wartezeiten. Dagegen wenn man nicht darauf zugreifen kann, dann sollte eine kurze Pause eingelegt werden. Derzeit sind nur eine gewisse Anzahl von Verbindungen pro Gegenstelle gleichzeitig erlaubt. Bitte beachten das der Auf- und Abbau einer Verbindung sich überschneiden kann.
RecaptchaV2 ist seit heute ausschließlich aktiv.
Diese Information ist leider nicht ganz korrekt. Google wollte es abschalten aber hat es bisher nicht vollständig umgesetzt.
Bisher erscheint wohl fast immer die Meldung vom Shutdown im Browser aber ein Captcha ist per Reloadbutton zu erhalten und funktioniert derzeit.
EDIT: Inzwischen wurde das System wohl heruntergefahren bei Google. Es kommt im Test nur noch die Meldung mit Shutdown seit 03.04.2018 um 00:35 Uhr.
Danke für Eure Erklärungen!
Möchte noch anmerken das es alles nur Beobachtungen und Erfahrungswerte sind. Gesicherte Informationen von Google existieren in der Regel nicht.
Das Optionale ist bestimmt noch ein Relikt von Zeiten wo standardmäßig zusätzlich immer localhost freigeschaltet war, aber thecoder2012 wird bestimmt mehr zu sagen können.
Habe jetzt doch einige Zeit mit RecaptchaV2 verbracht, ich bekomme kein gelöstes Captcha von 9kw.eu zurück, wenn man den Parameter "Pageurl" weglässt, obwohl er als "optional" gekennzeichnet ist.
Der Parameter ist weiterhin optional aber Google hat bereits vor geraumer Zeit bei ReCaptcha v2 die Prüfung auf die Url/Domain als Voreinstellung für Seitenbetreiber aktiviert.
Dazu ist die API auch nicht nur ReCaptcha v2 sondern auch für Keycaptcha, Coincaptcha und Funcaptcha. In Zukunft sicherlich noch weitere Formen. Das Prinzip selbst ist dabei immer gleich.
Sicherlich kann man die Dokumentation in Zukunft verbessern dazu.
Hmm, damit bekommt 9kw. eine schöne Linksammlung zusammen? Jede andere URL liefert kein korrektes Captcha.
Allgemein reicht es derzeit die Domain mit Subdomain zu übermitteln bzw. ggf. noch den Pfad. Meines Wissens ist die vollständige Url noch(!) nicht erforderlich.
Dazu kann der Captcha Dienst nichts für die fortlaufend geänderten Bedingungen von Google.
Ist es notwendig bei RecaptchaV2 die Quellenurl mitzuliefern? (also Doku zur API falsch)
In 99% der Fällen bei ReCaptcha V2 inzwischen ja. Man findet sicher noch ältere Schlüssel von Google.
Die Doku ist korrekt. Man könnte höchstens einen Hinweis anbringen das es bei bestimmten Arten wie ReCaptcha v2 erforderlich sein könnte.
Wie erfolgt eigentlich die Zuordnung, welches Captcha der User gerade hat?
Das System schaut welcher User frei ist und teilt es entsprechend zu.
Der public_key alleine kommt ja von der Seite, da ist ja noch keine Userinformation drinnen, also geht es nur über die Quellenurl?
Die Quellenurl wird erst beim Lösen benötigt in 99% der Fälle und nicht vorher. Google wendet viele Faktoren an und alle haben eine Gewichtung meines Wissens.
Wird die IP des einreichenden Users verwendet, um zu erkennen welcher User auf der Seite xy das Captcha anfordert?
Beim Lösen wäre der erste sichtbare Punkt für Google. Vorher ist ein Abruf im Prinzip bisher nicht nötig. Also wegen Datenschutz liegt ein Teil auch am Downloadtool.
Optimal wäre vermutlich es einmal am Tag abzurufen und im Cache zu speichern.
Ein Proxy als Beispiel ist erforderlich wenn Google unzufrieden mit 2 IP-Adressen ist.
Diverse Meldungen können erscheint. Ein Beispiel (hab grad die anderen Meldungen nicht zur Hand):
Hab für ReCaptcha v1 auch mal ein Bild unter http://ryblog.eu/fritzload/viewtopic.php?pid=3393#p3393 hinzugefügt.
Im Shareonline-Plugin habe ich deshalb einfach eine share-online-Seite als Parameter angegeben, die möglichst echt aussieht, aber nicht den echten Link verrät. Das war in der Hoffnung, dass die Captchas dadurch nicht zu schwer werden. Zugelassen wäre aber jede beliebige share-online Seite.
JDownloader 2 selbst reicht derzeit nur Domain inkl. Subdomain ein. Nur in Ausnahmen wie bei SJ wird eine angepasste Url gesendet.
Vom Datenschutz her kann man derzeit die Fileid einfach durch einen Zufallswert ersetzen. Die exakt gleiche Url dürfte eher auffällig wirken aber Fritz!Load hat ja keinen hohen Anteil.
Wobei unklar ist ob ggf. Lösungen dadurch abgelehnt werden könnten. Vermutung gibt es dazu aber bisher keine konkreten Beweise.
Da im Moment ja alle OCH die Captcha Dienste umstellen, und damit in den nächsten Wochen nicht jeden Tag ein neuer Thread aufgeht, dachte ich man kann das zusammenfassen.
Soweit ich weiß arbeitet Rolex0815 ja zur Zeit daran die ReCaptcha v2 Funktion auszulagern, damit man die Hoster im Anschluss leichter anpassen kann.
Ich selbst hab noch nicht im Code nachgeschaut aber meines Wissens wurde die Funktion bereits (halbwegs) ausgelagert und versucht eine automatische Erkennung hinzuzufügen. Wie weit damit jetzt die Hosterplugins ein Update benötigen weiß ich leider noch nicht. Hab es selbst aus Zeitmangel auch noch nicht testen können.
Kann nur so viel sagen das Pyload hinterher hinkt.
Um zumindest den letzten Teil denen einfacher zu machen die das auch wirklich können, dachte ich man könnte eine Liste anlegen.
Möchte ergänzen das ein Update nur bei Bedarf (oder bekannten Hostern) wirklich einen Sinn macht.
JDownloader 2 macht es nicht anders. Nur das dort mehr Nutzer und auch Entwickler beteiligt sind und die Außenwirkung erscheint oft so als würde es ohne dortige Meldung erledigt.
Ich biete gerne an diesen Thread einmal zu checken, und die Liste zu aktualisieren.
Gerne. Hilfe ist immer willkommen.
Naja müsste man sich wohl intensiver anschauen.
Nur eine Anmerkung:
Feedback kann auch bei RCv2 (interaktiven Captchas) gesendet werden aber hat lediglich keine Auswirkung auf das eigene Guthaben.
Die von @roadman17 erstellten recaptcha v2 solver Funktionen sind an die richtige Stelle gewandert.
Siehe https://sourceforge.net/p/avmload/code/2895/
Top!
Derweil ist die Erkennung ob recaptcha v2 vom Hoster verwendet wird noch nicht zuverlässig, aber das ist nur temporär, da ab 01.04.2018 nur mehr v2 gehen wird.
Könnte man nicht einfach einen zusätzlichen Wert übergeben ala "rcv2=1" oder sowas?
Bin mir unsicher ob die Erkennung sonst nicht mehrere Varianten abdecken müsste.
Das Problem löst sich am 31.03.2018 eh von selbst - wie ich im anderen Thread gesehen habe.
Ja. Ich verstehe nicht ganz warum man es automatisch erkennen muss. Allgemein kann ein Wert gesetzt oder übergeben werden. Wird in JDownloader 2 und anderen Tools auch so gemacht.
Denke mal nicht das Google und Seitenbetreiber nun alle 6 Monate das System wechseln.
Testlink: https://filer.net/get/oofl4bhzewzwyg8r (Cyberfox 52.x ESR)
Bei filer.net finde ich z.B. nichts, was auf api2 o.ä. hindeutet, nur den grundlegenden Link:
https://www.google.com/recaptcha/api.js
Vermutlich wird es bei Filer.net über Javascript alles eingefügt (=inspect element) und der reine HTML-Code ist sehr minimal (view source).
Das kann ich runterladen und mit grep nach api2 durchsuchen - dann gibt's in dem Fall eine Unterscheidung.
Das soll nur als Bsp. dienen - für's captcha Handling wie es jetzt in FL aktiv ist, braucht man eine immer funktionierende Methode und da kam ich eben noch nicht entscheidend weiter.
Grundsätzlich einen Wert übergeben oder vorher setzen. Da die Webseiten ganz sicher nicht 10 Änderungen am Tag durchführen. Sitekey könnte man ggf. so auch übergeben weil der verändert sich normalerweise auch nicht. Seitenbetreiber sind dafür zu 99% viel zu faul außer bei Faucetseiten.
Ich versuche gerade grundlegenden Support für Recaptcha v2 einzubauen.
Also im Großen und Ganzen die bereits geschriebene Funktionalität aus dem Plug-in in die entsprechenden Files zu schieben.
Klingt gut!
Gibt es eigentlich eine einfache Methode, um im Source der Seite zu erkennen, ob v1 oder v2 verwendet wird?
Ja eventuell schon. Neben eventuell leicht anderen Formfeldern ist vorallem üblicherweise "api" durch "api2" in der Url ersetzt worden.
Alt:
https://www.google.com/recaptcha/api/
Neu:
https://www.google.com/recaptcha/api2/
Ich fand nur einen komplizierten Weg, der aber noch verifiziert werden muss.
Kommt wohl auf den eingesetzten HTML-Code bzw. zusätzlichen Javascript-Code (z.B. callbacks) in der Seite auch drauf an.
Allerdings werden Seiten auf v1 nicht zurückjgehen, wenn v2 aktiv ist.
Es wurden bei 9kw.eu weiterhin ReCpatcha v1 Captchas eingereicht, aber die Seite selbst hat schon auf v2 umgestellt, wie ich im Edit beschrieben habe.
Leider hat man keinerlei Anhaltspunkte woher die ReCaptcha v1 Captchas kommen und kann daher auch keine Maßnahmen dagegen ergreifen außer eventuell zu viele fehlerhafte Rückmeldungen und sowas aufgreifen.
In den nächsten Wochen werden ja dann wahrscheinlich noch mehr Plugins ausfallen wenn ReCaptcha v1 wirklich abgeschaltet wird.
Allgemein hat Google dazu Benachrichtigungen an die Webmaster versendet und es für den 31. März 2018 angekündigt.
Ich zitiere mal die E-Mail von Google dazu:
Action required: reCAPTCHA v1 API shutdown on March 31, 2018
Dear Webmaster,
You are receiving this email because you are registered as a website administrator using reCAPTCHA, and your website is still using reCAPTCHA v1, which will be turned off on March 31, 2018.
We announced the reCAPTCHA v1 deprecation in May 2016. Starting in November 2017, a small percentage of reCAPTCHA v1 traffic will begin to show a notice informing users that the old API will soon be retired. Any calls to the v1 API will not work after March 31, 2018.
To ensure continued functionality, you’ll need to update your website to a current version of reCAPTCHA. You can learn more about reCAPTCHA v2, Invisible reCAPTCHA and reCAPTCHA Android API in our Developer’s Guide. The new APIs are simple to implement and will streamline the captcha experience for your users. If you need help, you can engage in the reCAPTCHA Google Developer Group or post to Stack Overflow with the ‘recaptcha’ tag.
We hope that your upgrade will be seamless, and we’re confident you’ll be happy with the results.
Thank you,
reCAPTCHA Support
Und ja ich finde die Fristen von Google und anderen Firmen viel zu kurz.
Beim jDownloader hat man das Plugin jetzt nach drei Tagen angepasst.
Soweit ich weiß ist ja auch der Open Source, vielleicht kann das ja Inspiration bieten ReCaptcha v2 auch bei filer.net zu lösen.
Ein Problem ist das die aktuelle Umsetzung für den Captcha Dienst in Fritz!Load hardcodiert im SO Hosterplugin vorgenommen wurde. Es müsste erst noch angepasst werden müsste, damit verschiedene Hosterplugins funktionieren. Vermutlich. Nach und nach werden alle Seiten mit RCv1 auf RCv2 wechseln wohl.
7170 ist schon eine alte Box und vermutlich kaum mehr Mainstream.
Kam selbst leider bisher noch nicht wieder zu weiteren Tests und überprüften positiven Änderungen im Code.
Wer kann Zeile 126 im Code erklären?
https://sourceforge.net/p/avmload/code/ … ine_biz.sh
Also die Frage ist wer hat Zeile 126 geschrieben? Die Person kann es sicher auch erklären. Ich habe es jedenfalls nicht geschrieben.
Der zweite Parameter pageurl sollte doch dynamisch sein?
Der hardcodierte Link ist das Testfile lotto-spieleinsatz.pdf.
Naja vermutlich reicht Subdomain+Domain bei SO derzeit aus aber allgemein sollte es dynamisch sein.
Hab mich sowieso gewundert das es im SO Plugin hardcodiert eingefügt wurde weil andere Hosterplugins längerfristig auch umgestellt werden müssten.
Wenn das mal offline ist, geht das Plugin nicht mehr ...
Reupload und Zeile erneuern hilft.
Seit heute Vormittag werden alle Captchas als Selfsolve eingereicht.
Nehme mal an es handelt sich nur um ReCaptcha v1. Sonst sollte kein Selfsolve automatisch aktiv werden können.
Die Einstellung dafür habe ich mehrmals aus und an "getoggelt". Ändert sich nicht...
Dürfte eine Schutzmaßnahmen sein und gilt nur bei ReCaptcha v1. Wird vollständig nach max. 2 Stunden automatisch zurückgesetzt.
Du meinst zum Auslagern, damit man nicht soviele Punkte auf dem Konto hat die dann ggf. verbraten werden?
Ja. Würde allgemein die Limits pro Stunde so setzen, das etwas mehr als der Durchschnitt durchgehen kann aber ein Amoklauf von Fritz!Load stark verlangsamt wird.
Den Fehler reproduzieren ist wirklich blöd, das einzige was funktioniert ist 30 Links (z.B. á 100 MB, was dann so ca 12 h dauern sollte bei Free-User-Speeds) einzuspeisen und die ganze Sache laufen zu lassen.
Wenn der Fehler auftritt und man kein Guthaben mehr hat, wird dann einfach von Fritz!Load weiter gemacht?
Irgendwann tritt es dann auf. Die kompletten Logs davon habe ich noch, aber das sind halt 9000 Zeilen, nicht anonymisiert
Auszüge die ich durch Suche nach Bad-Request gefunden habe können oben gesehen werden, wo ich sie mit Umfeld gepostet habe. Wo sonst die Captcha ID zurückgegeben wird kommt stattdessen ein HTML-Header.
Hab die meisten geposteten Auszüge überflogen aber fande leider nichts hilfreiches um das Problem zu reproduzieren.
Läuft außer Fritz!Load noch etwas auf der Fritzbox wodurch es ggf. schneller vorkommt als woanders?
Hab nur eine 7170 (mit Freetz) die einfach im Netzwerk mitläuft aber sonst gar nichts macht außer Fritz!Load auf einem USB Stick (interner Speicher ist zu klein).
Konntest du denn das auseinanderlaufen der Timer auf deiner 7170 bestätigen?
Nein. Der neue Code mit "date" funktionierte grundsätzlich nicht korrekt im Test. Es wäre nur denkbar das sowas vorkommen könnte.
Hatte mit r2878 ansich das Problem mit "./fritzload.sh: line 1: date+%s: not found" behoben (Tippfehler vom anderen Entwickler) aber im Test danach ging es weiterhin nicht.
Meine Box ist ziemlich voll gepackt. Fast jede Standard AVM Funktion ist aktiv und es läuft noch Freetz mit Samba und FTP. Aber Ram und Prozessorlast sind nie auch nur annähernd am Anschlag deswegen machte ich mir da bisher keine Sorgen.
Normalerweise ist das auch kein Problem aber die Verzögerung ist schon ungewöhnlich.
In der Zwischenzeit wurde R2877 eingecheckt, die Zeit scheint jetzt über die Uhrzeit zu laufen, anstatt das die FritzBox aktiv zählt, was ihren zarten Prozessor wohl aus dem Tritt brachte.
Gibt es dazu einen Kommentar ob ich das richtig sehe?
Werde das mal einspielen und laufen lassen...
Scheint aber leider nicht richtig zu laufen. Dachte es sei nur ein Leerzeichen zu wenig ("date+%s" vs. "date +%s") aber im Test ging es trotzdem nicht.
Hab nun eine 7170 als Testobjekt zur Hand.
Das du so viele Credits verloren hast tut mir leid, ich habe mir angewöhnt immer die Userhistory von 9kw.eu nebenher aufhzuhaben, dann kann man sowas schneller erkennen.
Tipp: Guthaben als Gutschein erstellen wenn möglich und einfach wieder selbst nutzen den Gutschein. Das System erlaubt eine solche Nutzung.
Sonst ggf. die Nutzung der Captchas pro Stunde auf 5 einschränken bei Tests.
Würde empfehlen den Timeout eher höher zu stellen, wenn man von diesen Schwierigkeiten betroffen ist. Ggf. kann man auch zwei Timeouts integriert, einmal für 9kw und einmal für Fritz!Load intern.
Das du auch Bad Request Fehler hast ist gut zu hören, also bin ich nicht verrückt.
Ich dachte nie das man verrückt ist aber ein Problem festzustellen das nur selten vorkommt ist schwierig.
Hatte im Test alle möglichen Probleme und Meldungen aber keinen einzigen Bad Request bisher.
Sobald man das Problem gezielt reproduzieren kann, dann kann es auch sicherlich behoben werden.
Im Moment ist nur R2876 wirklich stabil.
Hab die Änderungen vorhin sowohl von mir als auch vom anderen Entwickler vorläufig rückgängig gemacht und sollte R2867 entsprechen zzgl. Felder für den Proxy unter Einstellungen.
Laut 7170 läuft es mit R2887 dann erstmal so wie vorher mit R2876.
Von Zeit zu Zeit fährt sich das Plugin fest und schafft es irgendwie nicht mehr richtig das Captcha bei 9kw einzureichen, es sind für diese Zeit auch keine Einreichungen in der History.
Läuft es denn manchmal mehrere Stunden ohne Schwierigkeiten?
Das mit dem Timeout bzw. das Fritz!Load es ggf. nicht erneut versucht, klingt tatsächlich nach einem Bug.
Allgemein wie erwähnt absichtlich per Sandbox (selfsolve) mal entweder nichts eingeben (timeout auf 60 stellen) oder einfach eine falsche Lösung eingeben.
Davon dann eine Log machen um es explizit ohne störende Faktoren nachvollziehen zu können.
Euer Server laggt immer wieder mal, häufig gegen 21 Uhr deutscher Winterzeit.
Dann kommt logischerweise häufiger mal keine Antwort zurück, oder das gesendete Captcha verläuft im Sand. Deswegen kann man zu dieser Uhrzeit schonmal so einen Fehler loggen.
Nutzt man zufällig IPv6? Falls ja, könnte man es mit nur IPv4 testen?
Viele bezeichnen es in Englisch als "Captcha Flow" (flüssige Captchaverarbeitung), so das einfach die Antwort trotz einem schnellen Server länger dauert als erwartet. Gründe können unterschiedlich sein.
Natürlich können Serverprobleme nicht ausgeschlossen werden aber ein genauer Tag und Uhrzeit wäre hilfreich statt "häufig gegen 21 Uhr" zwecks Überprüfung ggf. mit Angabe genutzter Funktion.