INFO App Update Android (v1.4.25)

[Aldrift]

Was für ein Gesetz, dass man auf lokale IPs nicht HTTP oder.. OK werden wir strenger,  dass man  HTTPS self-signed verwenden darf? 😂

Nein ehrlich ich weiß was Du meinst, aber in Betracht auf den Vorschlag hier gibt es m.E. keine wirkliches (auch gesetzliches) Kontra.

Aber ja ich gebe Dir Recht viele der Richtlinien sind nur Steine die man in den Weg gelegt bekommt, aber man sollte sich wie in diesem Fall keinen eigenen Stein ans Bein binden 🙂 

 

Bitte melde dich an um den Link zu sehen.

 um auch diesen Berecih nochmal zu prüfen, OK es werden Login Daten übertragen, also z.B. "passwort@name" über den Usernamen in der App, um sich so bei einem Serve zu authentifizieren und anzumelden. Im internen/lokalen Netzwerk könnte einer das über HTTP "sniffen" und damit einen User "spoofen", aber sobald Ihr self-signed HTTPS auf lokale IPs verwendet, dann ist auch das nicht mehr möglich, denn hier könnte nur der Serverbetreiber im lokalen Netzwerk das Passwort über HTTPS self-signed entschlüsselen, und das muss er natürlich nicht, denn er hat es ja sowieso. Somit wäre mein Vorschlag ganz klar: bleibt bei HTTPS im öffentlichen Netzwerken und im  lokalen Netzwerk sind IPs( 192er, 172er, 10er) auf self-signed HTTPS beschränkt. Das würde ja ausreichen, dann muss kein HTTP zum Einsatz kommen. Im übrigen ist derzeit es auch nicht mit (zumindest dem Iphone) in Einklang, DENN, erstelle ich eine eigen Root CA und gebe diese im Iphone explizit als Trusted an, auch dann verbindet sich die App nicht; das heißt Ihr seit derzeit strenger als Apple 😄 Aber es darauf zu entwickeln, dass Ihr die Trusted CAs im Iphone abfragt und es dann zumindest zulässt, erscheint mir mehr Aufwand als Nutzen, d.h. wie oben beschrieben HTTPS self-signed auf 192er, 172er, und 10er IPs es zuzulassen müsste ausreichen und vom Aufwand her sehr überschaubbar sein 🙂 lg

Bearbeitet 8. Dezember 2024 von Aldrift

[Aldrift]

Am 6.12.2024 um 17:19 schrieb Martin:

so machen wir es. Ich bespreche noch mal und Du remindest;)

Bitte melde dich an um den Link zu sehen.

 Frohes Neues Jahr!! Ich hoffe Du und SK sind gut reingedriftet 🥳 Hier der kleine Reminder und weiß auch nicht ob Du meinen letzten Post (weil es editiert hinzugefügt hatte) bereits gesehen hattest (siehe oben) Weiterhin bin ich stark dafür auf (nur!) lokale IPs self-signed zuzulassen.

PS wenn ich das hier von Bernd lese, dann denke glaub auch die meisten dass dies auch wieder kommen wird 🙏 wie gesagt imo erweitert es das Spiel ungemein und auf nur lokale IPs mit noch self-signed seid Ihr safe.

Am 18.11.2024 um 09:44 schrieb B-Unit:

..., da fehlt aber das Update aktuell, dass "http" wieder freigeben ist. Dann hast du für dich im privaten Rahmen eine kostenfreie Alternative.

LG Alex

 

[B-Unit]

Bitte melde dich an um den Link zu sehen.

Okay, hast recht. Ich editiere es mal raus aus meinem Beitrag, wenn das letzte Statement von Martin halt anders aussieht.

[Aldrift]

vor einer Stunde schrieb B-Unit:

Bitte melde dich an um den Link zu sehen.

Okay, hast recht. Ich editiere es mal raus aus meinem Beitrag, wenn das letzte Statement von Martin halt anders aussieht.

Martin prüft ja noch, ist nichts ganz final entschieden, sollte nur zeigen dass der ein oder ander (wie auch ich bis vor kurzem noch) denkt es ist ein Bug im Update und wird noch irgendwann behoben; dass der "Bug zum Feature wird" mit LOKALEN IPs + https-self-signed,  sehe ich eigentlich gute Chance für, ich drücke die Daumen und soll ja hier ab und wann reminden 😄 

[Aldrift]

Am 6.12.2024 um 17:19 schrieb Martin:

so machen wir es. Ich bespreche noch mal und Du remindest;)

Reminder

Bitte melde dich an um den Link zu sehen.

😁 

Please please please.. Drift API wieder auf lokale IPs mit HTTPS self-signed freischalten 🙏

Bearbeitet 28. Januar von Aldrift

[steffl]

Bin hier nur zufällig vorbeigekommen, möchte

Bitte melde dich an um den Link zu sehen.

 und seinen Entwicklern aber folgende Punkte mitgeben:

Wichtig ist "Secure by default", es sollte rechtlich gesehen okay sein eine unsichere Kommunikation anzubieten, solang sich der Anwender dessen bewusst ist (durch entsprechende Warnungen, wenn er auf http umstellt bzw. vor jedem Connect).
Ehrlich gesagt gehen über die API außer evtl. dem Passwort eh keine sensiblen Daten...

Eine andere Option wäre die Variante mit "self-signed" Zertifikaten: Benutzer bestätigen lassen, dass er diesem Zertifikat vertraut und gut ist. Dann kann sich die App auch den Fingerprint merken und darüber zukünftig den Trust herstellen.

[Aldrift]

vor 30 Minuten schrieb steffl:

Bin hier nur zufällig vorbeigekommen, möchte

Bitte melde dich an um den Link zu sehen.

 und seinen Entwicklern aber folgende Punkte mitgeben:

Wichtig ist "Secure by default", es sollte rechtlich gesehen okay sein eine unsichere Kommunikation anzubieten, solang sich der Anwender dessen bewusst ist (durch entsprechende Warnungen, wenn er auf http umstellt bzw. vor jedem Connect).
Ehrlich gesagt gehen über die API außer evtl. dem Passwort eh keine sensiblen Daten...

Eine andere Option wäre die Variante mit "self-signed" Zertifikaten: Benutzer bestätigen lassen, dass er diesem Zertifikat vertraut und gut ist. Dann kann sich die App auch den Fingerprint merken und darüber zukünftig den Trust herstellen.

Dank für Deinen Input 🙂👍 Schau auch mal weiter oben bzw. zurück, da habe ich auch mal alles beleuchtet und denke auch man macht HTTPS auf öffentliche IPs auf jeden Fall und lokale IPs, die nur im internen Netzwerk vergeben werden können (10,172,192er),  mit HTTPS self-sign, das dürft m.E. soweit dann alles im absolut hellgrünen Bereich sein

[Aldrift]

Am 28.1.2025 um 10:01 schrieb Aldrift:

Reminder

Bitte melde dich an um den Link zu sehen.

😁 

Please please please.. Drift API wieder auf lokale IPs mit HTTPS self-signed freischalten 🙏

Bitte melde dich an um den Link zu sehen.

 Wie besprochen ab und zu ein kleiner Reminder 🙏 lg

Bearbeitet 26. März von Aldrift

[Aldrift]

 wie besprochen, Reminder

Bitte melde dich an um den Link zu sehen.

Drift API wieder auf lokale IPs mit HTTPS self-signed freischalten 🙏

 

[Jash]

Die Tage hatte mich Martin auch nochmal wegen dem Thema angesprochen. Mit einer der letzten Updates der DR!FT-App wurde ja zugrundeliegende die Unity-Version aktualisiert, was die unbeabsichtigte (!) Folge hatte, dass http nicht mehr unterstützt wird. War also keine Absicht oder ähnliches (und hat auch nichts mit DR!FTCLUB zu tun). 

Ob die jetzt in der DR!FT-App verwendete Unity-Version technisch überhaupt http unterstützt ist aktuell noch offen. 

Daraus ergibt sich für Sturmkind die wirtschaftliche Frage ob die Kosten/Investition das herauszufinden und ggf. http in lokalen Netzwerken wieder möglich zu machen gegeben sind. Wieviele Entwickler/Hobbytüftler (neben

Bitte melde dich an um den Link zu sehen.

 😜) vermissen das Feature direkt im lokalen Netzwerk sich zu verbinden*?

Die grundlegende Idee der API war und ist Multiplayer für DR!FT verfügbar zu machen. Das ist mit DR!FTCLUB auf sehr einfache Art und Weise (teils kommerziell) Realität geworden, was vermutlich die Motivation einen eigenen Multiplayer-Server zu entwickeln wohl auch etwas mindern wird.

*Via Tools wie ngrok lässt sich aber ein lokaler Server für die Community-API (kostenfrei) sehr einfach (wieder) verfügbar machen. Das hat sogar den Vorteil, dass Teilnehmer sich über ihre eigene Internetverbindung dem lokalen Server beitreten können, ohne dass diese sich in ein lokales WLAN einwählen oder irgendwelche Trust-Profile auf ihr Telefon einrichten müssen. 
 

Bitte melde dich an um den Link zu sehen.

 Ich weiß du bist kein Fan von Tools oder dem Konzept von ngrok, weil ein externes Tool einen Tunnel auf einen spezifischen Port in dein lokales System aufbaut. Aber dafür musst du nicht Gästen dein WLAN-Zugang geben 😉

Fazit: Ich vermute, dass hier Sturmkind keine wirtschaftlichen Sinn sieht http für lokale Netze wieder funktional zu bekommen, weil:
- kaum Nachfrage
- via Tools wie ngrok funktioniert es (sogar besser 😳)
- DR!FTCLUB 😜
 

 

[MOSkorpion]

Bitte melde dich an um den Link zu sehen.

dann kann man DriftClub auch gleich nativ verbinden ohne URL, account usw.

Ich schätze niemand nutzt die API mehr für was anderes als DriftClub und das würde den Einstieg nochmal einfacher machen. 

[THR3360]

vor 1 Stunde schrieb MOSkorpion:

Bitte melde dich an um den Link zu sehen.

dann kann man DriftClub auch gleich nativ verbinden ohne URL, account usw.

Ich schätze niemand nutzt die API mehr für was anderes als DriftClub und das würde den Einstieg nochmal einfacher machen. 

Mit dem gleichen Argument, wieso SK vermutlich nicht an einer Änderung bzgl http arbeiten wird (Ressourcen) kann man die Option Alternative zu Driftclub offen halten. Wie oft änderst du denn deinen Zugang? Wieviel Lizenzen hast du mit einem SK Account bei Driftclub?

 

Bitte melde dich an um den Link zu sehen.

 Im übrigen ist das Problem mit dem hängenden Sound bei Android nicht restlos behoben. Das ist immer noch Buggy.

Es kommt manchmal ab Start bei mir vor, dass dieser Soundbug wieder einsetzt. Verhängnigsvoll ist dabei diesmal, dass das Auto sich nicht mehr richtig steuern lässt. Es ist träger, langsamer.

Bearbeitet 8. Juni von THR3360

[NorthWave]

vor 2 Stunden schrieb MOSkorpion:

Bitte melde dich an um den Link zu sehen.

dann kann man DriftClub auch gleich nativ verbinden ohne URL, account usw.

Könnte man machen, aber Driftclub gehört ja nicht zu Sturmkind, sondern ist ja eigenständig. Dann hätte man sich die API ja auch schenken können. Ich denke aber, dass seitens SK nichts mehr bezüglich der API passieren wird. 

[Martin]

Am 7.6.2025 um 12:43 schrieb Jash:

Die Tage hatte mich Martin auch nochmal wegen dem Thema angesprochen. Mit einer der letzten Updates der DR!FT-App wurde ja zugrundeliegende die Unity-Version aktualisiert, was die unbeabsichtigte (!) Folge hatte, dass http nicht mehr unterstützt wird. War also keine Absicht oder ähnliches (und hat auch nichts mit DR!FTCLUB zu tun). 

Ob die jetzt in der DR!FT-App verwendete Unity-Version technisch überhaupt http unterstützt ist aktuell noch offen. 

Daraus ergibt sich für Sturmkind die wirtschaftliche Frage ob die Kosten/Investition das herauszufinden und ggf. http in lokalen Netzwerken wieder möglich zu machen gegeben sind. Wieviele Entwickler/Hobbytüftler (neben

Bitte melde dich an um den Link zu sehen.

 😜) vermissen das Feature direkt im lokalen Netzwerk sich zu verbinden*?

Die grundlegende Idee der API war und ist Multiplayer für DR!FT verfügbar zu machen. Das ist mit DR!FTCLUB auf sehr einfache Art und Weise (teils kommerziell) Realität geworden, was vermutlich die Motivation einen eigenen Multiplayer-Server zu entwickeln wohl auch etwas mindern wird.

*Via Tools wie ngrok lässt sich aber ein lokaler Server für die Community-API (kostenfrei) sehr einfach (wieder) verfügbar machen. Das hat sogar den Vorteil, dass Teilnehmer sich über ihre eigene Internetverbindung dem lokalen Server beitreten können, ohne dass diese sich in ein lokales WLAN einwählen oder irgendwelche Trust-Profile auf ihr Telefon einrichten müssen. 
 

Bitte melde dich an um den Link zu sehen.

 Ich weiß du bist kein Fan von Tools oder dem Konzept von ngrok, weil ein externes Tool einen Tunnel auf einen spezifischen Port in dein lokales System aufbaut. Aber dafür musst du nicht Gästen dein WLAN-Zugang geben 😉

Fazit: Ich vermute, dass hier Sturmkind keine wirtschaftlichen Sinn sieht http für lokale Netze wieder funktional zu bekommen, weil:
- kaum Nachfrage
- via Tools wie ngrok funktioniert es (sogar besser 😳)
- DR!FTCLUB 😜
 

 

Danke Matthias, es ist (leider) genau so. Die aktuelle Unity Version unterstützt HTTP nicht mehr. Das war uns vorher auch nicht bewusst. Wäre es uns bekannt gewesen, hätte das aber auch nichts geändert. Um aktuell zu bleiben und diverse Probleme lösen zu können, mussten wir  aktuallisieren.

Bitte melde dich an um den Link zu sehen.

Jetzt hast Du so lange gehofft - tut mir sehr Leid. Sowohl technisch, als auch aufgrund der Datenschutzthematik wird es bei HTTPS bleiben müssen. Vielleicht schaust Du Dir ngrok, oder ähnliche Lösungen noch einmal an. Ich bin mir sicher, Du/Ihr findet da noch einen Weg;)

[Aldrift]

Am 8.6.2025 um 21:43 schrieb Martin:

Danke Matthias, es ist (leider) genau so. Die aktuelle Unity Version unterstützt HTTP nicht mehr. Das war uns vorher auch nicht bewusst. Wäre es uns bekannt gewesen, hätte das aber auch nichts geändert. Um aktuell zu bleiben und diverse Probleme lösen zu können, mussten wir  aktuallisieren.

Bitte melde dich an um den Link zu sehen.

Jetzt hast Du so lange gehofft - tut mir sehr Leid. Sowohl technisch, als auch aufgrund der Datenschutzthematik wird es bei HTTPS bleiben müssen. Vielleicht schaust Du Dir ngrok, oder ähnliche Lösungen noch einmal an. Ich bin mir sicher, Du/Ihr findet da noch einen Weg;)

Bitte melde dich an um den Link zu sehen.

 

Bitte melde dich an um den Link zu sehen.

Verstehe euch nicht und auch die Argumentation ist nicht schlüssig, einzig "will nicht" ist argumentativ einleuchtend 😂 es geht um HTTPSSSSS mit self-signed Zertifikaten (und falls sicherheitstechnische bedenken das lediglich auf lokale IPs). Was man schreibt und sich Mühe gibt das zu beleuchten, ging wohl einmal ins eine Ohr und drüben wieder raus 😅Der Aufwand das freizuschalten bzw. zu implementieren ist minimal und ergibt enorme Vorteile, naja ich geb's auf, wer nicht will der hat schon.. schade, have fun. 

 

PS wenn ich einmal google nach support unity https wird das im übrigen unterstützt:

Yes, Unity supports HTTP. Specifically, Unity uses the UnityWebRequest class to handle both HTTP and HTTPS requests, allowing games to interact with web servers.

ob das allerdings ist wie es geschrieben wird ist mir dann jetzt auch egal, ich akzeptiere dass es nicht gewollt ist.

Bearbeitet vor 23 Stunden von Aldrift