TCPServer Session/Eindeutige ID ermitteln

[himitsu]

Hier geht eben keine automatische Sessionverwaltung.
Bei TCP ist "standardmäßig" eine Session nur so lange, wie die Connection arbeitet und wird nicht automatisch über mehrere Connections geshared.
Das mußt du übernehmen.
(auch bei HTTP ist das nicht standardmäßig drin, aber kann mit vorhandenen Funktionalitäten umgesetzt werden)

1: Bei der ersten Connection eine ID generieren und an den Clienten senden (er speichert sie in den Cookies).
2: Der Client sendet diese ID dann innerhalb seine Session bei nachfolgenden Connections wieder an dich zurück.
3: Du schaust dann ob eine ID übermittelt wurde (wenn nicht, dann Punkt 1) und setzt/nutzt für nachfolgende Connections (innerhalt der Session der einzelnen TCP-Verbindungen) die übermittelte ID (nach Authentifizierung, dass diese ID auch noch gültig ist ... wenn nicht dann zu 1).

So wird z.B. die Session-Verwaltung hier im Forum gehandhabt.



Wenn Cookies gesperrt sind, dann könnte man die Session-ID als Parameter in die URL einbauen.
Nach dem Laden der ersten Seite eine Weiterleitung zur URL inkl. SessionID und dann auf der Webseite auch alle Links mit dieser ID anpassen/erweitern.

Alternativ kann man die Session eben anhand der IP verwalten, aber da geht pro IP nur eine Session. (auf HTTP-Ebene kann man das noch um Browser-Kennung und Dergleichen erweitern)
- der Server speichert sich zur IP eine Session-ID oder nutzt die IP direkt als ID.

[DelTurbo]

Hi,
so habe ich es vor. Allerdings weiß ich nicht wie ich an diese (sagen wir mal ID) drankomme. Ich bekomme beim Connecten, egal ob es die 1. oder 2. usw. ist. Folgendes:

Code:

GET /set_config_webServices.html?tab=WebServices&menu=WebServicesConfig HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://192.168.0.2:800/info_specialPages.html?tab=Home&menu=InfoPages
Accept-Language: de-DE
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 192.168.0.2:800
DNT: 1
Connection: Keep-Alive


GET /hp/device/defaultnew.css HTTP/1.1
Accept: text/css, */*
Referer: http://192.168.0.2:800/set_config_webServices.html?tab=WebServices&menu=WebServicesConfig
Accept-Language: de-DE
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 192.168.0.2:800
DNT: 1
Connection: Keep-Alive


GET /hp/device/bullet.gif HTTP/1.1
Accept: image/png, image/svg+xml, image/*;q=0.8, */*;q=0.5
Referer: http://192.168.0.2:800/set_config_webServices.html?tab=WebServices&menu=WebServicesConfig
Accept-Language: de-DE
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 192.168.0.2:800
DNT: 1
Connection: Keep-Alive

Leider habe ich noch nicht rausgefunden wie ich "per Hand" (ich bin ja auf der TCP ebene) mit dem Client "reden" kann. Ich habe eben mal in HttpWatch und WireShark nachgesehen was so hin und her geht. Schlauer hat es mich nicht gemacht. Ob wohl ich eine Param.Value setze sehen ich das nirgends.
Das habe ich mit einem IdHTTPServer gemacht. Dabei ist mir augefallen das 10.6.2.0 einen Parameter mehr hat als 10.6.0.0. Und zwar SessionIDCookieName.

Was ich nun gemacht habe, ist, ich lasse auf einen IdHTTPServer Connecten, verwende dort die Authentifizierung und setze dort diesen Param.Value. Dann gebe ein Redirect auf ServerIP:800 raus. Dort läuft der LowLevel TCPServer. Aber, wie gesagt, ich habe keinerlei Ahnung wie ich dort wieder an den Param komme den ich gesetzt habe.

Erst mal vielen dank für die Hilfe. Wenn du irgendwo eine Demo hast, wo man sieht wie man im TCPServer an die Param kommt wäre ich sehr dankbar.

Gruß

[himitsu]

Zitat:

Code:

GET /set_config_webServices.html?tab=WebServices&menu=WebServicesConfig HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://192.168.0.2:800/info_specialPages.html?tab=Home&menu=InfoPages
Accept-Language: de-DE
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 192.168.0.2:800
DNT: 1
Connection: Keep-Alive

xxxxxxxxx
xx
x
x
x
x
x
x

Bis zur ersten Leerzeile ist das der HTTP-Header.
Die erste Zeile davon ist der Befehl an den Server (Quelle der Daten und die Version des HTTP-Protokoll) und den Rest stell dir wie eine INI vor (: statt =), wo dir der Server ein paar Verbindungsparameter und Informationen übergibt. (z.B. auch die Cookies)
-> HTTP-Request mit Header+Data

Sowas gibt es auch beim Senden der Antwort, wo ebenfalls erst ein Header und anschließend die Daten rausgehn.
Erste Zeile der Statuscode und dann eben Paramater zum Auswerten der Antwort (Format der Daten), Datum und auch die zu schreibenen Cookie.
-> HTTP-Response mit Header+Data

https://www.mediaevent.de/tutorial/http-request.html
https://developer.mozilla.org/de/docs/Web/HTTP/Cookies
https://developer.mozilla.org/en-US/...ers/Set-Cookie
https://de.wikipedia.org/wiki/HTTP-Cookie

[DelTurbo]

Danke, die Links werde ich mir mal ansehen.

Was ganz merkwürdiges, ich hatte eben im Log wirklich mehrmals Cookie mit der Cookie ID drin stehen. Ich weiß leider nicht warum. Ich habe nix geändert. Man könnte sagen von ca. 50 mal stand es 5 mal drin.

Wäre das immer da, dann wäre das endlich mal fertig.

Vielen vielen dank für deine Hilfe. Heute werde ich allerdings nichts mehr machen. Kann nichtmehr sitzen...

[Zacherl]

Willst du auch SSL unterstützen? Dann kannst du das Injecten deiner Session nämlich leider auch vergessen. Für andere Protokolle als HTTP natürlich sowieso. Ich würde nach wie vor auf dem SOCKS Protokoll aufbauen, sofern du natürlich Kontrolle über die Browser/Anwendungen hast und dort deinen Server als Proxy einstellen kannst.

[DelTurbo]

Hi Zacherl,
den Socks von Indy habe ich mir mal angesehen. Weil ich muss SSL können. Deswegen habe ich nun an dieser stelle erst mal aufgehört. Es bringt ja nix wenn es nur ohne SSL läuft.

Aber wie ich das was weiterleiten habe ich nicht so richtig kapiert. Hättest zu das vielleicht ein Stückchen Source für mich worauf ich aufbauen kann?

Vielen dank im Voraus

[himitsu]

SSL kann dennoch unterstützt werden.

Client/Browser <SSL> deineProxyAnwendung <SSL> derZielServer


hier kann man einmal die SSL-Verschlüsselten Daten 1:1 durchreichen
oder Client/Browser <SSL> deineProxyAnwendung und deineProxyAnwendung <SSL> derZielServer nutzen jeweils ein eigenes SLL-Zerzifikat (sie können auch das Selbe nutzen, aber eben jeder)
Client/Browser <SSL> deineProxyAnwendungClientside <X> interneVerbindungUndDatenauswertungUndCookiemanipulationOhneSLL <X> deineProxyAnwendungServerside <SSL> derZielServer

Du bist also kein dummer "ich reich allers durch"-Proxy, sondern für den clöient bist du der Server und für den Server bist du der Client und jeweils dazwischen kommt das SSL rein.