10-17 19:57:36.753 8821 17793 D DOWNLOAD: downloading timetable list
10-17 19:57:36.993 8821 17793 W System.err: godau.fynn.dsbdirect.manager.DownloadManager$CredentialsIncorrectException
10-17 19:57:36.997 8821 17793 W System.err: at godau.fynn.dsbdirect.manager.DownloadManager.downloadTimetableList(DownloadManager.java:139)
10-17 19:57:36.997 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity.getTimetables(MainActivity.java:229)
10-17 19:57:36.998 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity.access$000(MainActivity.java:66)
10-17 19:57:36.998 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity$3.run(MainActivity.java:185)
10-17 19:57:36.998 8821 17793 W System.err: at java.lang.Thread.run(Thread.java:764)
Hier mal der adb logcat:
```
10-17 19:57:36.753 8821 17793 D DOWNLOAD: downloading timetable list
10-17 19:57:36.993 8821 17793 W System.err: godau.fynn.dsbdirect.manager.DownloadManager$CredentialsIncorrectException
10-17 19:57:36.997 8821 17793 W System.err: at godau.fynn.dsbdirect.manager.DownloadManager.downloadTimetableList(DownloadManager.java:139)
10-17 19:57:36.997 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity.getTimetables(MainActivity.java:229)
10-17 19:57:36.998 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity.access$000(MainActivity.java:66)
10-17 19:57:36.998 8821 17793 W System.err: at godau.fynn.dsbdirect.activity.MainActivity$3.run(MainActivity.java:185)
10-17 19:57:36.998 8821 17793 W System.err: at java.lang.Thread.run(Thread.java:764)
```
=> Wieder wie bei #38
Dabei ist das die minimalistischste Anfrage. Seit heute muss ein 'LastUpdate' mitgeschickt werden. Dabei ist es egal, welches Datum (habe auch 2000 und 1970 gestestet und es läuft. AppID sieht nach einer UUID aus. Diese darf allerdings nicht random generiert werden.
Ich kann gerade nicht weitertesten, da ich '503 The service is unavailable.' bekomme
Hier ein Teil der Lösung:
```
{
"AppId":"4f0261d6-9963-4398-ad90-3373e1e31373",
"PushId":"",
"UserId":"user",
"UserPw":"pw",
"AppVersion":"2.5.9",
"Device":"",
"OsVersion":"",
"Language":"",
"Date":"",
"LastUpdate":"2019-10-04T14:18:5122700",
"BundleId":""
}
```
Dabei ist das die minimalistischste Anfrage. Seit heute muss ein 'LastUpdate' mitgeschickt werden. Dabei ist es egal, welches Datum (habe auch 2000 und 1970 gestestet und es läuft. AppID sieht nach einer UUID aus. Diese darf allerdings nicht random generiert werden.
Ich kann gerade nicht weitertesten, da ich '503 The service is unavailable.' bekomme
Jip. War gerade beim Testen. 503 habe ich davor nicht bekommen. DSBDirect erkennt das aber auch und sagt, dass ich offline bin. Evtl. noch den Error code parsen und schauen, ob es wirklich am Internet liegt? Du könntest ja überprüfen, wenn nicht 200 und kein time out, dann sagen: Serverfehler,...
Jip. War gerade beim Testen. 503 habe ich davor nicht bekommen. DSBDirect erkennt das aber auch und sagt, dass ich offline bin. Evtl. noch den Error code parsen und schauen, ob es wirklich am Internet liegt? Du könntest ja überprüfen, wenn nicht 200 und kein time out, dann sagen: Serverfehler,...
Im Fall, dass der Server nicht antwortet, entsteht eine IOException, da kann ich nicht unterscheiden, ob das am Server oder an der Client liegt. 503 dürfte eigentlich eine LoginFailureException (Ungültige Antwort) (ehemals CredentialsIncorrectException) sein.
Der Server steht jetzt wieder.
Im Fall, dass der Server nicht antwortet, entsteht eine IOException, da kann ich nicht unterscheiden, ob das am Server oder an der Client liegt. 503 dürfte eigentlich eine `LoginFailureException` (Ungültige Antwort) (ehemals `CredentialsIncorrectException`) sein.
Der Server steht jetzt wieder.
Ich merke gerade, dass die offizielle DSB App von den Play Diensten so stark abhängt, dass diese nicht einmal starten...
Okay. Dann teste ich mal weiter...
Ich merke gerade, dass die offizielle DSB App von den Play Diensten so stark abhängt, dass diese nicht einmal starten...
Okay. Dann teste ich mal weiter...
Meine Ergebnisse sind im Moment leider sehr unaufschlussreich. Mal geht was, mal nicht. Gerade geht es nicht mal, eine Anfrage, die DSBmobile vom body her genau so generiert hat, abzusenden.
Meine Ergebnisse sind im Moment leider sehr unaufschlussreich. Mal geht was, mal nicht. Gerade geht es nicht mal, eine Anfrage, die DSBmobile vom body her genau so generiert hat, abzusenden.
Nein, nur den erforderlichen Content-Type-Header. Das habe ich mir heute morgen erst überlegt, dass die auch über den news service aktualisiert werden sollten.
Nein, nur den erforderlichen `Content-Type`-Header. Das habe ich mir heute morgen erst überlegt, dass die auch über den news service aktualisiert werden sollten.
Es liegt wohl eher doch nicht am Host-Header, das war wohl Zufall.
Ich schicke die gleiche Anfrage mehrmals hintereinander und manchmal geht's und manchmal nicht.
Übrigens das gleiche in der DSBmobile-App. Da steht im Fall des Fehlschlags "Login Fehlgeschlagen. Kennung oder Passwort falsch.". Diesen Fehler habe ich auch schon gemacht…
Wie wir wissen, braucht die Firma immer eine Weile, bis Änderungen auf alle Server deployed sind.
Es liegt wohl eher doch nicht am `Host`-Header, das war wohl Zufall.
Ich schicke die gleiche Anfrage mehrmals hintereinander und manchmal geht's und manchmal nicht.
Übrigens das gleiche in der DSBmobile-App. Da steht im Fall des Fehlschlags "Login Fehlgeschlagen. Kennung oder Passwort falsch.". Diesen Fehler habe ich auch schon gemacht…
Wie wir wissen, braucht die Firma immer eine Weile, bis Änderungen auf alle Server deployed sind.
Ich würde vorschlagen, dass wir das FrontEnd wechseln. Von https://app.dsbcontrol.de/JsonHandler.ashx/GetData zu https://www.dsbmobile.de/JsonHandlerWeb.ashx/GetData
Dort muss man keine Metadaten setzten (noch nicht). Eine Anfrage sieht so aus:
Wichtig ist aber, dass dort ein folgender Header gesetzt wird:
Referer: test
Ich würde vorschlagen, dass wir das FrontEnd wechseln. Von ```https://app.dsbcontrol.de/JsonHandler.ashx/GetData``` zu ```https://www.dsbmobile.de/JsonHandlerWeb.ashx/GetData```
Dort muss man keine Metadaten setzten (noch nicht). Eine Anfrage sieht so aus:
```
{"UserId":"id","UserPw":"pw","Abos":[],"AppVersion":"","Language":"de","OsVersion":"","AppId":"","Device":"","PushId":"","BundleId":"","Date":"","LastUpdate":""}
```
Wichtig ist aber, dass dort ein folgender Header gesetzt wird:
```
Referer: test
```
Das braucht aber ein Update der App, es wäre mir lieber, wir könnten 2.5.2 mit dem News-System reparieren. Google Play kaut schon seit gestern um etwa 15 Uhr an dem Update rum, ohne es auszuliefern, und bei F-Droid geht das systembedingt auch nicht so schnell.
Das braucht aber ein Update der App, es wäre mir lieber, wir könnten 2.5.2 mit dem News-System reparieren. Google Play kaut schon seit gestern um etwa 15 Uhr an dem Update rum, ohne es auszuliefern, und bei F-Droid geht das systembedingt auch nicht so schnell.
habe auch gleich die 2.5.3 geändet im Code. Das taggen überlasse ich dir, da ich nicht meine Signatur verwenden will. Das würde einige fustrierte Gesichter machen: "Installation fehlgeschlagen"
//closed
Nach obwohl: #42
habe auch gleich die 2.5.3 geändet im Code. Das taggen überlasse ich dir, da ich nicht meine Signatur verwenden will. Das würde einige fustrierte Gesichter machen: "Installation fehlgeschlagen"
//closed
Ging nämlich bei mir vorhin mal so und auch jetzt gerade.
Taggen mit angehängter Datei kann man eh nur im GUI.
Ich würde jetzt auch mal `queryBodyBaseJson` per news experimentellerweise setzen auf:
{"AppId":"4f0261d6-9963-4398-ad90-3373e1e31373","AppVersion":"2.5.2","Device":"","OsVersion":"","Language":"","Date":"","LastUpdate":"zurfrühstueckszeit","BundleId":""}
Ging nämlich bei mir vorhin mal so und auch jetzt gerade.
Habe ich auch gesetzt, allerdings hatte ich da das Problem, dass es mal ging und mal nicht (eher nicht). Allerdings weiß ich nicht, wie "auffällig" das ist mit der AppId. Kann es sein, dass es nur per Login ist oder ähnliches? Da hätte ich eher Angst
Habe ich auch gesetzt, allerdings hatte ich da das Problem, dass es mal ging und mal nicht (eher nicht). Allerdings weiß ich nicht, wie "auffällig" das ist mit der AppId. Kann es sein, dass es nur per Login ist oder ähnliches? Da hätte ich eher Angst
Wo hast du denn deine AppId her? Ist die von mir oder ist das einfach so die gleiche?
Im Übrigen hatte ich keine Zeit, die news zu testen. Ich glaube, sie gehen nicht -.-
Wo hast du denn deine AppId her? Ist die von mir oder ist das einfach so die gleiche?
Im Übrigen hatte ich keine Zeit, die news zu testen. Ich glaube, sie gehen nicht -.-
Die ist tatsächlich von dir:) Ich hätte auch eine eigene genommen, allerdings kann ich DSBmobile nicht mal ansatzweise zum Laufen bringen ohne Gapps.
Ist aus #36
Habe gerade nach zahlreichen Versuchen mit installierten news einmal beobachten können, dass es funktioniert. Da ist "Manchmal geht's, manchmal nicht" ja schon übertrieben.
Dachte ich mir…
Habe gerade nach zahlreichen Versuchen mit installierten news einmal beobachten können, dass es funktioniert. Da ist "Manchmal geht's, manchmal nicht" ja schon übertrieben.
Immer, wenn ein Loginfehler auftritt (im Onboarding oder im Normalgebrauch), kommt jetzt ein Knopf "nach einer Fehlerbehebung suchen", sie die Nachrichten anzeigt und queryBodyBaseJson übernimmt. In Debugbuilds gibt es im Menü einen Knopf "Neuigkeiten herunterladen."
Mir ist noch aufgefallen, dass DSBmobile weniger Anmeldefehler bekommt als DSBDirect. Ich schreibe das mal in die Nachrichten, dann ist aber endgültig gut für heute.
Immer, wenn ein Loginfehler auftritt (im Onboarding oder im Normalgebrauch), kommt jetzt ein Knopf "nach einer Fehlerbehebung suchen", sie die Nachrichten anzeigt und queryBodyBaseJson übernimmt. In Debugbuilds gibt es im Menü einen Knopf "Neuigkeiten herunterladen."
Mir ist noch aufgefallen, dass DSBmobile weniger Anmeldefehler bekommt als DSBDirect. Ich schreibe das mal in die Nachrichten, dann ist aber endgültig gut für heute.
Auch eine Möglichkeit das ganze issue zu schließen.
Ich habe diese Änderung gemacht. "Mein" DSBDirect sollte deswegen gegen weitere Änderungen immun bleiben, da bis jetzt alle "Runden" nur den App Endpoint betroffen haben und nicht den Web Endpoint.
Auch eine Möglichkeit das ganze issue zu schließen.
Ich habe diese Änderung gemacht. "Mein" DSBDirect sollte deswegen gegen weitere Änderungen immun bleiben, da bis jetzt alle "Runden" nur den App Endpoint betroffen haben und nicht den Web Endpoint.
Previous: #38
Ich werde mich leider erst später heute Abend darum kümmern können. Ich hoffe, das News-System #39 hilft uns hier weiter!
Hier mal der adb logcat:
=> Wieder wie bei #38
Hier ein Teil der Lösung:
Dabei ist das die minimalistischste Anfrage. Seit heute muss ein 'LastUpdate' mitgeschickt werden. Dabei ist es egal, welches Datum (habe auch 2000 und 1970 gestestet und es läuft. AppID sieht nach einer UUID aus. Diese darf allerdings nicht random generiert werden.
Ich kann gerade nicht weitertesten, da ich '503 The service is unavailable.' bekomme
503 bekam ich auch. Ich hätte fast geschrieben, das wäre die Ursache für den Fehler. Jetzt antwortet der Server gerade gar nicht mehr.
Jip. War gerade beim Testen. 503 habe ich davor nicht bekommen. DSBDirect erkennt das aber auch und sagt, dass ich offline bin. Evtl. noch den Error code parsen und schauen, ob es wirklich am Internet liegt? Du könntest ja überprüfen, wenn nicht 200 und kein time out, dann sagen: Serverfehler,...
Im Fall, dass der Server nicht antwortet, entsteht eine IOException, da kann ich nicht unterscheiden, ob das am Server oder an der Client liegt. 503 dürfte eigentlich eine
LoginFailureException(Ungültige Antwort) (ehemalsCredentialsIncorrectException) sein.Der Server steht jetzt wieder.
Ich merke gerade, dass die offizielle DSB App von den Play Diensten so stark abhängt, dass diese nicht einmal starten...
Okay. Dann teste ich mal weiter...
Die normale ja, die mit IHK-Skin oder andere Varianten interessanterweise nicht.
Meine Ergebnisse sind im Moment leider sehr unaufschlussreich. Mal geht was, mal nicht. Gerade geht es nicht mal, eine Anfrage, die DSBmobile vom body her genau so generiert hat, abzusenden.
Uff
Es fehlt der
Host-Header.Schickst du den nicht mit?
Nein, nur den erforderlichen
Content-Type-Header. Das habe ich mir heute morgen erst überlegt, dass die auch über den news service aktualisiert werden sollten.Habe gerade in einer Testversion die changed gehardcoded. Läuft nicht mehr. Lief kurz.
Es liegt wohl eher doch nicht am
Host-Header, das war wohl Zufall.Ich schicke die gleiche Anfrage mehrmals hintereinander und manchmal geht's und manchmal nicht.
Übrigens das gleiche in der DSBmobile-App. Da steht im Fall des Fehlschlags "Login Fehlgeschlagen. Kennung oder Passwort falsch.". Diesen Fehler habe ich auch schon gemacht…
Wie wir wissen, braucht die Firma immer eine Weile, bis Änderungen auf alle Server deployed sind.
Diese "Warnung" habe ich gesehen. habe gerade auch ein git pull gemacht. Meine "alte" Version lief, aber die hatte die Meldung noch nicht....
Sie haben tatsächlich ihre eigene App (teil)kaputt gemacht. Ich glaube, ich schreibe das mal so in die News.
Ich merke es gerade#:)
Der Webknotenpunkt läuft noch....
Ich würde vorschlagen, dass wir das FrontEnd wechseln. Von
https://app.dsbcontrol.de/JsonHandler.ashx/GetDatazuhttps://www.dsbmobile.de/JsonHandlerWeb.ashx/GetDataDort muss man keine Metadaten setzten (noch nicht). Eine Anfrage sieht so aus:
Wichtig ist aber, dass dort ein folgender Header gesetzt wird:
Das braucht aber ein Update der App, es wäre mir lieber, wir könnten 2.5.2 mit dem News-System reparieren. Google Play kaut schon seit gestern um etwa 15 Uhr an dem Update rum, ohne es auszuliefern, und bei F-Droid geht das systembedingt auch nicht so schnell.
Ich vermute, du kannst in deiner Web-Anfrage ebenfalls
PushIdganz weglassen.Das weiß ich nicht. Damit es wieder funktioniert musst du folgende Änderungen machen
(bin grad zu faul den code zu commiten, pushen, mergen, ...)Nach obwohl: #42
habe auch gleich die 2.5.3 geändet im Code. Das taggen überlasse ich dir, da ich nicht meine Signatur verwenden will. Das würde einige fustrierte Gesichter machen: "Installation fehlgeschlagen"
//closed
Taggen mit angehängter Datei kann man eh nur im GUI.
Ich würde jetzt auch mal
queryBodyBaseJsonper news experimentellerweise setzen auf:Ging nämlich bei mir vorhin mal so und auch jetzt gerade.
Habe ich auch gesetzt, allerdings hatte ich da das Problem, dass es mal ging und mal nicht (eher nicht). Allerdings weiß ich nicht, wie "auffällig" das ist mit der AppId. Kann es sein, dass es nur per Login ist oder ähnliches? Da hätte ich eher Angst
Wo hast du denn deine AppId her? Ist die von mir oder ist das einfach so die gleiche?
Im Übrigen hatte ich keine Zeit, die news zu testen. Ich glaube, sie gehen nicht -.-
Die ist tatsächlich von dir:) Ich hätte auch eine eigene genommen, allerdings kann ich DSBmobile nicht mal ansatzweise zum Laufen bringen ohne Gapps.
Ist aus #36
Dachte ich mir…
Habe gerade nach zahlreichen Versuchen mit installierten news einmal beobachten können, dass es funktioniert. Da ist "Manchmal geht's, manchmal nicht" ja schon übertrieben.
Eigentlich schon blöd....die eigene App lahmlegen. Die haben wahrscheinlich Serverprobleme. Wo kann man denn die News sehen? Nur beim Anmelden, oder?
Immer, wenn ein Loginfehler auftritt (im Onboarding oder im Normalgebrauch), kommt jetzt ein Knopf "nach einer Fehlerbehebung suchen", sie die Nachrichten anzeigt und queryBodyBaseJson übernimmt. In Debugbuilds gibt es im Menü einen Knopf "Neuigkeiten herunterladen."
Mir ist noch aufgefallen, dass DSBmobile weniger Anmeldefehler bekommt als DSBDirect. Ich schreibe das mal in die Nachrichten, dann ist aber endgültig gut für heute.
Anscheinend haben sie die Änderungen vom Donnerstag wieder rückgängig gemacht.
Auch eine Möglichkeit das ganze issue zu schließen.
Ich habe diese Änderung gemacht. "Mein" DSBDirect sollte deswegen gegen weitere Änderungen immun bleiben, da bis jetzt alle "Runden" nur den App Endpoint betroffen haben und nicht den Web Endpoint.