#1
|
|||
|
|||
Anzeige der Restzeit zum Aktivieren des Recaptcha
Hallo,
ich komme nicht immer gleich dazu, die Recaptchas zu lösen und so passiert es mir immer wieder, dass ich ein Recaptcha löse und im Hintergrund läuft der Timeout ab. Wenn ich dann das Recaptcha gelöst habe sehe ich den Dialog zum erneuten Start des Dialogs. Mein Wunsch wäre nun eine Anzeige der verbleibenden Zeit bis zum Timeout im Dialog zum Starten des Recaptcha. Mir würde hier schon eine ungefähre Angabe ausreichen, so in 5 oder 10 Sekundenschritten. Gruß |
#2
|
||||
|
||||
Du meinst die Anzeige der Restzeit im Browser? Weil in der App und im Dialog ist diese ja vorhanden
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
Ja. Entschuldigung, da war ich wohl etwas ungenau.
|
#4
|
||||
|
||||
Ich leite diesen Thread mal an den Entwickler der Erweiterung weiter
__________________
JD-Dev & Server-Admin |
#5
|
||||
|
||||
Eine Anzeige wäre sicherlich wünschenswert. Noch besser wäre es wenn das gelöste Captcha für den neuen Downloadvorgang genutzt werden könnte, wenn der Sitekey identisch bleibt.
Das Captcha ist ja meist nur für den JDownloader selbst abgelaufen aber nicht für die Seite oder Google. Da der Timeout von 120 Sekunden ja erst nach erhaltener Lösung anfängt bei RCv2.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#6
|
||||
|
||||
Du meinst, JDownloader bekommt von einem Solver einen Antwort Token für RC und statt diesen *wegzuwerfen*, lieber einfach mal prophylaktisch aufheben und für die nächste Challenge mit gleichem Sitekey aufheben und dort probieren? Hast du denn Erfahrung wie lange ein Antwort Token gültig bleibt? Die Idee würde sich bestimmt relativ einfach umsetzen
__________________
JD-Dev & Server-Admin |
#7
|
||||
|
||||
Quote:
Bei Google hat der Token eine Gültigkeit von 120 Sekunden. Die Zeit fängt an, wenn die Lösung produziert wurde. Schätze mal das JD dann so 110 Sekunden als maximale Zeit haben dürfte für eine tatsächliche Nutzung.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#8
|
||||
|
||||
Danke für die Rückmeldung. Sprich ein Token das nicht genutzt wurde, könnte man ja 100-110 Sekunden *aufheben* und erst dann als *unused* melden. Geht das mit jeder Seite/Token oder hast du da Erfahrung das bestimmte Seiten da zusätzliche *Prüfungen* haben, ala...ein Captcha in 2 Sekunden, sehr *unglaubwürdig*
__________________
JD-Dev & Server-Admin |
#9
|
||||
|
||||
Quote:
Ich wüsste auch spontan nicht wie man eine solche zusätzliche Prüfung als Seitenbetreiber einbauen könnte. Die Recaptcha v2 API sieht nur eine IP- und Domainüberprüfung vor.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#10
|
||||
|
||||
Kurze Frage noch, wie oder wann genau erhälst du das Token dann? Wenn JDownloader das Captcha als *abgelaufen* markiert, werden ja alle laufenden Solver dafür abgebrochen und somit wartet der Solver ja auch gar nicht mehr auf eine Antwort des Dienstes. Mir fällt derzeit nur die Situation ein, das der Dienst die Antwort schickt und just in diesem Moment der Timer abläuft. Oder hab ich eine Situation/das Gesamtbild falsch verstanden?
__________________
JD-Dev & Server-Admin |
#11
|
||||
|
||||
Erwarte auch keine Wunder von so einer Idee. Es würde die Anzahl der nervigen Captchas nur sehr leicht reduzieren.
Quote:
Würde sagen 10-80 Sekunden als zusätzliche Zeit dürfte es beim CES noch denkbar sein, danach nicht mehr weil dann eine Fehlermeldung zurückgegeben werden sollte, falls keine Lösung existiert oder per Unused der Vorgang abgebrochen wurde (zumindestens bei 9kw). Aber nicht endgültig auf eine Fehlermeldung vom CES verlassen sondern dann z.B. nach zusätzlichen 80 Sekunden wirklich intern den Prozess killen. Bzgl. BrowserAddon/myjd/mobileApps wird es wohl schwieriger mit einem endgültigen Timeout und da sollte man es eher über ein Lebenszeichen vielleicht realisieren. Damit JDownloader die Lösung noch annimmt. Quote:
Paar Beispiele: 1. Error 404 bei Filecrypt und im nächsten Moment ist es wieder freigegeben. Hatte dazu hier ja schon etwas geschrieben. Testlink mit RCv2 und Filecrypt: filecrypt.cc/Container/D038279069.html filecrypt.cc/Container/B4DB35316E.html (mit Mathematical operation/letters) (Im Test kam 3x das gewünschte Captcha wie RCv2 am Anfang per Reload immer und dann doch wieder CutCaptcha obwohl im Account/Folder abgewählt, RCv2 ist auf 10 Abrufe pro Stunde limitiert) 2. Abbruch vom Nutzer (z.B. stop+start) 3. Doppelte Lösungen (z.B. über zwei CES doppelt gelöst oder per BrowserAddon zeitgleich) 4. Proxy ist unerwartet nicht mehr nutzbar und der Request ging daneben. 5. Fehlerhandling in Plugins und kurzfristige *Wartungsarbeiten* (treten *gefühlt* alle 3 Minuten auf) 6. Der Timer läuft gerade ab wenn JD die Antwort erhalten hat. Mir fallen grad die anderen Möglichkeiten im JD nicht ein aber wenn JD "unused" erzeugt, dann liegt die Lösung ja bereits vor. Ich wusste ja nicht das ich eine Liste (ggf. mit Statistik) irgendwann mal bräuchte darüber.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#12
|
||||
|
||||
Hier gibts nur ein Problem. Es gibt zwei Szenarien
1.) Der Solver schickt eine Antwort, welche nicht mehr benötigt wird, weil abgebrochen/timeout/anderer Solver schneller. In diesem Fall könnte man die Antwort für eine kurze Zeit cachen und bei Bedarf nochmals nutzen, was deinem Vorschlag entspricht 2.) Captcha wurde agebrochen/timeout/anderer Solver ist schneller, aber der aktuelle Solver hat noch KEINE Antwort geschickt. Hier entsteht jetzt das *Problem*. Entweder blockiert der Solver erstmal und wartet auf eine Antwort/Reaktion des Servers/Solvers oder wir brechen den Solver ab und werden somit nie erfahren was die Antwort des Servers gewesen wäre. Für 1.) müsste man lediglich das Senden von Unused verzögern und die Antwort zwischenspeichern und später wiederverwenden oder eben dann als Unsed markieren
__________________
JD-Dev & Server-Admin |
#13
|
||||
|
||||
Quote:
Bei doppelten Antworten eine davon nehmen, die andere in den Cache für max. 120 Sekunden. Es würde natürlich etwas mehr Systemressourcen benutzt wenn zwei Solver laufen (regulär + nur auf Antwort wartend). Aber bisher kann man ja auch z.B. 10 Captchas gleichzeitig lösen lassen. Ich weiß auch nicht genau wie viel Arbeit es wäre beide Szenarios zu berücksichtigen. Ja manche Wege sind einfacher. Aber Rom wurde ja hoffentlich auch nicht in einem Tag erbaut.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#14
|
||||
|
||||
Ich hab das ganze mal in ein Ticket verlinkt, aber derzeit fehlt mir hier die Zeit für Proof-of-Concept oder Tests
__________________
JD-Dev & Server-Admin |
#15
|
||||
|
||||
Quote:
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. Last edited by thecoder2012; 03.07.2019 at 22:29. |
#16
|
||||
|
||||
Bzl XDCC: JA, das *packt* mich auch viel mehr und hätte da mehr Bock drauf
__________________
JD-Dev & Server-Admin |
Thread Tools | |
Display Modes | |
|
|