Beiträge von misterspeed

Warum soll TCPlisten nur mit Class C Netzen funktionieren? TCPlisten wird auf Serverseite genutzt und kann an jede beliebige IPv4 Adresse des Servers gebunden werden.

Vorraussetzung für erfolgreiche Verbindungen zum erstellten Server Socket ist:

- Softwarefirewall / Virenschutzlösung des Servers und evtl. vorhandene Hardwarefirewall des Serverhosters erlaubt eingehende TCP Verbindungen zur gewünschten IP Adresse und Port aus dem Client Netzwerk

Du solltest dein Problem nochmals genauer beschreiben und Begrifflichkeiten wie Server und Client nicht durcheinander würfeln. Ein Client ist passiv und kann nur dann angesprochen werden wenn er bereits erfolgreich eine Verbindung zum Server hergestellt hat. Ein Server ist hingegen normalerweise permanent von beliebig vielen Clients ansprechbar, sofern er dafür konzipiert wurde.

Wenn du also wissen willst ob ein Client da ist brauchst du nur am Server prüfen ob es eine aktive Verbindung gibt und dem verbundenen Client meinetwegen eine Frage stellen, damit er dem Server antwortet (oder halt auch nicht wenn er doch inzwischen offline sein sollte...).

Du bekommst Seitenquelltext zurück? Ich bekomme bei meinem Script nur den Header (bei der API URL mit oAuth Token, bei der normalen URL ohne) und leeren Inhalt für $aReturned[1] zurück, trotz gültiger Zugangsdaten (bin auch bei Congstar).

Auf manchen Webseiten sieht man im Quelltext wie der HTML Quellcode dynamisch aus JS Aufrufen bestimmter API Seiten generiert wird. Seh ich hier auf Anhieb aber leider auch nichts von.

Was ist eigentlich das Ziel wenn man mal fragen darf? Nur den aktuellen Guthabenstand auslesen oder hast du mehr im Sinn? Mich nervt, dass man als Prepaid Kunde keine übersichtliche monatliche Abrechnung bekommt und die Detaildaten wo man sich das dann selber nachrechnen könnte nach 90 Tagen gelöscht werden. Letztlich kann man nur blind drauf vertrauen dass da alles korrekt abgerechnet wird oder darf das ständig manuell kontrollieren.

Mir fehlt da einfach der Überblick was mich der Spaß neben dem Grundpreis so im Monat kostet...

Das schaut jedenfalls besser aus, dann bekommt man auch einen oauth token im header zurück, so wie oben in seinem Mitschnitt.

Über die API URLs lassen sich vermutlich dann auch alle anderen Infos auslesen, die in der Webansicht so geladen werden.

Ein Blick in den Seitenquellcode verrät vermutlich welche API Aufrufe durchgeführt werden um die Daten dynamisch nachzuladen.

Hab mal selber ein wenig gespielt. Zwar nicht erfolgreich, aber immerhin bekomm ich eine Antwort vom Server. Ein Fehler bei dir ist, dass du beim connect das Protokoll mit angibst. Hier wird nur der Servername erwartet, also lass das "https://" weg. Außerdem sollte der Request und dein Konsolenoutput etwas angepasst werden damit du mehr Infos erhältst und besser debuggen kannst.

Hier mal eine angepasste Fassung:

#Region ;************ Includes ************
#include <WinHttp.au3>
#EndRegion ;************ Includes ************

Global $hOpen = _WinHttpOpen('Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0')
Global $hConnect = _WinHttpConnect($hOpen, "www.congstar.de")
Global $sUser = "xxx"
Global $sPW = "xxxx"

Global $aReturned = _WinHttpSimpleSSLRequest($hConnect, "POST", "/login", Default, '{"username":"' & $sUser & '","password":"' & $sPW & '","defaultRedirectUrl":"/meincongstar","targetPageUrlOrId":"225424"}','Content-Type: application/json; charset=utf-8',True,1)
$err = @error
Global $aReturned2 = _WinHttpSimpleSSLRequest($hConnect, "GET", "/meincongstar", Default, Default,Default,True,1)
$err2 = @error

ConsoleWrite($err & @CRLF & "---------" & @CRLF & $aReturned[0] & "---------" & @CRLF & $aReturned[1] & @CRLF & "--------" & @CRLF)
ConsoleWrite($err2 & @CRLF & "---------" & @CRLF & $aReturned2[0] & "---------" & @CRLF & $aReturned2[1] & @CRLF & "--------" & @CRLF)

_WinHttpCloseHandle($hConnect)
_WinHttpCloseHandle($hOpen)

Warum im Response Array Feld weder beim einen noch beim anderen Request etwas zu sehen ist ist mir nicht ganz klar...

Ahja ich würd oben im Mitschnitt den "Set-Cookie" Teil grundsätzlich ebenfalls zensieren... jenachdem wie lange die Login / cookie session bei congstar hält und ob diese an deine IP gebunden ist kann man damit evtl. auf deinen Account zugreifen. Mittlerweile ist die Session aber vermutlich eh abgelaufen. Im Zweifel ändere dein Passwort und melde dich ab / an.

Ja Zeile 9 sagt dir was dein Browser da verschickt hat und in Zeile 13 sieht man auf den ersten Blick, dass es sich um JSON formatierten Text handelt, zumindestens wenn man schonmal JSON gesehen hat.

Normalerweise ist der serverseitige parser auch gescheit genug um selbst zu erkennen was man ihm da schickt oder er geht einfach davon aus, dass er das richtige bekommt. D. h. du musst normalerweise winhttp nichtmal sagen was er als verwendetes Format (Content-Type) im Header angeben soll. Kann man aber natürlich trotzdem machen, siehe Doku der winhttp Funktionen.

JSON Funktionen brauchst du garnicht. Die braucht man bestenfalls wenn man vom Server JSON zurückbekommt und sich keinen eigenen String Parser basteln will um an den relevanten Inhalt zu kommen. Ein einfaches stringbetween oder eben regexp langt dafür normalerweise aber völlig. Für dich irrelevant, da du keine API ansprichst und sowieso ne html seite zurückbekommst die du dann irgendwie mit den Stringfunktionen auswerten musst.

Hier mal konkret wie dein POST ausschauen sollte:

#Region ;************ Includes ************
#include <WinHttp.au3>
#EndRegion ;************ Includes ************

;~ ShellExecute("https://www.congstar.de/login") ;Einloggseite

Global $hOpen = _WinHttpOpen()
Global $hConnect = _WinHttpConnect($hOpen, "https://www.congstar.de")

Global $sUser = "TestUser"
Global $sPW = "TestPW"


Global $sReturned = _WinHttpSimpleSSLRequest($hConnect, "POST", "/login", Default, '{"username":"' & $sUser & '","password":"' & $sPW & '","defaultRedirectUrl":"/meincongstar","targetPageUrlOrId":"225424"}')

ConsoleWrite($sReturned & @CRLF)
_WinHttpCloseHandle($hConnect)
_WinHttpCloseHandle($hOpen)

Ungetestet. Und es könnte sein, dass du nach dem erfolgreichen Login noch ein GET für die gewünschte Seite hinterherschicken musst. Keine Ahnung ob dich der Login selbst schon zur Hauptseite weiterleitet und dir die gewünschte HTML Seite zurückgibt. Normalerweise bekommst du bei erfolgreichem Login jedenfalls die Aufforderung "Set-Cookie" vom Server wie oben im Mitschnitt zu sehen.

Und wie gesagt... es wäre möglich dass Username und Passwort codiert werden müssen um Syntaxproblemen vorzubeugen. Eine geschweifte Klammer und Anführungszeichen reichen schon um die JSON Formatierung zu zerstören.

Formfill ist da glaub ich eher ungeeignet, da das Formular nicht wirklich Standard zu sein scheint. Deinem Mitschnitt zu Folge erwartet der Webserver einen JSON formatierten String:

 {"username":"xxx","password":"xxx","defaultRedirectUrl":"/meincongstar","targetPageUrlOrId":"225424"}

Dabei muss man evtl. noch vorsichtig sein wenn es zu Syntax Kollisionen mit Sonderzeichen im Passwort / Username kommt. Könnte sein dass normalerweise das JS auf der Seite entsprechendes Escaping oder Codieren leistet, damit dies nicht zu Fehlern führt. Sollte dem so sein musst du das natürlich entsprechend nachbauen. Da du dein Passwort zensiert hast kannst du das aber nur selbst beurteilen. Bedenke halt, dass spätere Passwortanpassungen ggf. dann doch noch entsprechendes Codieren erfordern könnten, auch wenn es jetzt grad mangels problematischer Sonderzeichen nicht danach ausschaut.

Für Firefox gabs mal das Addon "Live HTTP Headers". Damit kann man sich die Serveranfragen und Antworten im Detail ansehen, also auch die Feld-/Parameternamen, welche bei einem GET/POST versendet werden.

Da Firefox das Addonsystem vor einiger Zeit verändert hat gibt es dieses Addon glaube ich nicht mehr, scheinbar gibt es aber mittlerweile eine ähnlich benannte Alternative.

https://addons.mozilla.org/de/firefox/addon/http-header-live/

Ob das Addon das selbe leistet kann ich aber nicht sagen. Schaut jedenfalls grundsätzlich nach dem richtigen Analysetool aus. Alternativ gibt es sicher auch für Chrome ein vergleichbares Addon.

Zitat von Mars

Leider ist die FF automatisierung den andauernden Updates zum Opfer gefallen. Es nervt einfach, dass man quasi jede Woche seine UDF überarbeiten muss damit sie wieder läuft.

Deswegen hab ich als ich das noch genutzt habe einfach eine Portable Version mit deaktivierter Update Funktion beigelegt. WinHTTP ist und bleibt trotzdem die wesentlich performantere Alternative.

Ahja falls wer die zip Dateien aus dem MozRep Repo für die Installation nutzen will... vermutlich reicht es die Dateiendung zu xpi zu ändern. Falls nicht findet man hier detailierte Informationen wie eine Addon XPI Datei organisiert sein muss. Grundsätzlich ist das nur eine ZIP-Datei mit fester Unterordner Struktur und bestimmten Dateien die Firefox erwartet.

https://developer.mozilla.org/en-US/docs/Arc…refox_extension

XPI Dateien sollten per Drag&Drop mit passender Firefox Version installierbar sein.

Da Mozilla das Mozrepl Addon auch nicht mehr zum Download anbietet muss man sich das ganze direkt aus dem Github Repo des Entwicklers beschaffen:

https://github.com/bard/mozrepl/releases

Wie und ob man das dann aber in der letzten kompatiblen FF Version installiert bekommt weiß ich nicht.

Zukunft hat das ganze jedenfalls keine. Ich würde daher etwas Zeit investieren und mein Script auf WinHTTP umstellen. Ist sowieso wesentlich performanter als igrendeine Browser Steuerung je sein könnte. Davon ab bist du unabhängig vom jeweiligen Clientsystem und dessen Browser.

Davon ab ist deine If-Bedingung syntaktisch falsch. Da fehlt ein logischer "Or" Operator zwischen den verschiedenen Prüfungen.

Ich war zugebenerweise auch auf einer auf IT spezialisierten Schule und hab da meine Ausbildung zum Informatiker gemacht.

Aber selbst da gab es Sicherheitsvorfälle wie "Fake Windows Anmeldebildschirme" um Zugangsdaten abzugreifen... die IT dort hat es sicher nicht leicht ihr Netzwerk sicher zu halten.

Zitat von chesstiger

Gut, das passiert ja hoffentlich, bevor Schüler den Raum betreteten

Ich würde das Kabel einfach am Tag oder Kurs davor abziehen

Sofern du einfacher Benutzer bist wirst du dich schwer tun Prozesse abzuschießen die im Kontext eines Administrators oder gar SYSTEM Dienstes laufen. Das kann man schon entsprechend verhindern.

Auch gegen Manipulationen der Hardware (wie z.B. Trennen des Netwerkkabels) kann man sich schützen. Bei uns waren deswegen alle Clientrechner in abgeschlossenen Tischboxen ohne direkten Zugang zur Verkabelung.

Kenn ja die Umgebung nicht, aber oft ist sowas bereits Teil der Infrastruktur, daher auch der Hinweis darauf. Grundlegende Netzwerksicherheit sollte auch in einer Schule vorhanden sein. Gibt da ja sicher nicht nur Schüler Clients, sondern auch Clients und Server der Verwaltung, welche grundsätzlich schonmal netwerktechnisch separiert gehören. Wenn eine Schule Prüfungen am PC ermöglicht erwarte ich schon, dass eine entsprechende IT Infrastruktur vorhanden ist.

PS: Das Empfangen der "sicheren" GPO kann man ganz simpel durch kurzes Trennen des Netzwerkkabels am Client im richtigen Moment verhindern. Da brauch ich weder Adminrechte noch irgendwelche Zero-Day Lücken dafür.

Naja ich meinte schon eine zentrale Firewall und nicht die lokale. Denn bei deiner Variante bist du darauf angewiesen, dass der Nutzer keine Kontrolle darüber erlangt ob und wie die Firewall konfiguriert wird, was prinzipiell denkbar wäre. Viel besser ist es wenn der Nutzer keine Chance hat die Firewall zu konfigurieren, sprich eine Hardwarefirewall über die der Internetverkehr des ganzen Standortes abgwickelt wird. So handhaben wir das in unserer Firma. Wir können problemlos bestimmte Subnetze unterschiedlich reglementieren, die Verwaltungsoberfläche ist nur aus einem administrativen Subnetz erreichbar.

Seh ich wie meine Vorredner. Sicher gewährleisten kann man das nur wenn man das Netzwerk wirklich an zentraler Stelle kappt, sprich am Switch. Auch der Hinweis USB Ports zu sperren ist sehr wichtig, denn wenn ich bescheissen will brauch ich dazu nicht zwingend internet, sondern nur meinen Spickzettel. Den kann man sich im Übrigen auch ganz altmodisch in Papierform anfertigen oder etwas moderner auf dem Smartphone oder Taschenrechner (grins) speichern. Clevere Schüler legen sich sowas vielleicht auch rechtzeitig auf dem Rechner im Profilordner ab. Die Möglichkeiten zu Bescheissen sind einfach verdammt groß wenn man Prüfungen am PC ermöglicht.

Zurück zur Frage... technische Möglichkeiten das Internet zu sperren oder zu beschränken gibt es etliche:

- Physikalisch durch trennen der Netzwerkverbindung

- Per zentraler Firewall

- Per spezialisierter Software (z.B. Produkte bzgl. Kindersicherung)

- Per Script, welches die HOST Datei manipuliert

- Per Script welches die Netzwerkeinstellungen manipuliert (kein Gateway, kein DNS)

Wirksamer als technische Sperren sind aber evtl. Abschreckung und entsprechende Sanktionen.

Bei uns wurde z.B. angeblich eine Software eingesetzt, welche es dem Lehrer PC ermöglicht jederzeit den Bildschirminhalt aller Schüler PCs einzusehen. Ob das wirklich so war kann ich nicht sagen, jedenfalls wurde man in den IT Richtlinien darauf hingewiesen. Dadurch kann man wie mit einem Spickzettel jederzeit erwischt werden. Sind die Sanktionen entsprechend hoch wird sich jeder sehr genau überlegen ob er das Risiko eingehen möchte.

Prinzipiell könnte man das sogar so erweitern, dass die gesamte Session jedes Prüflings komplett mitgeschnitten wird und nach Prüfungsende überprüft werden kann.

Mit timerinit() initialisierst du einen neuen Timer und überschreibst dir den alten Wert aus der ini einfach. Macht also so schonmal keinen Sinn. Ob der Wert eines Timerinit() überhaupt Scriptübergreifend nutzbar ist weiß ich nicht. Würde ich mich jedenfalls niemals drauf verlassen.

Was willst du denn nun genau erreichen? Ich vermute du willst die Gesamtlaufzeit protokolieren, sprich das Script läut 5 Sekunden, danach nochmal 2 Sekunden und du willst dann 7 Sekunden als Ergebnis?

Dann verwende doch einfach timerdiff() und addiere die Werte.

Beispiel:

$iTimeOld = Int(IniRead(@TempDir & '\' & $sINI, 'Values', '$hTimer', Default))
$hTimer = TimerInit() ; Timer der aktuellen Scriptinstanz
IniWrite(@TempDir & '\' & $sINI, 'Values', '$hTimer', timerdiff($hTimer)+$iTimeOld) ; Neue Zeitdifferenz plus alte Zeitdifferenz in ini Schreiben

Gegen ein Browser Plugin spricht meiner Meinung nach übrigens, dass sich Browser viel zu schnell verändern. Siehe Problematik bei Firefox und der überarbeiteten Plugin API. Ob Chrome in der jetzigen Form in 5-10 Jahren überhaupt noch existiert kann man heute auch schlecht abschätzen.

Naja kenne deine PDF Drucker Lösung nicht. Wir verwenden teilweise FreePDF. Damit ist es möglich Vor- und Nachgestellte beliebige Scripte zu definieren. Ob dabei der Originaldateiname durchgeschleift werden kann weiß ich gerade nicht, ich denke aber das sollte möglich sein. Sofern das passt kannst du dir zumindestens den Zwischenschritt "Parsing" der PDF schenken, bzw. das auf Auswerten des Dateinamens minimieren. Stilles Drucken oder zur Not Dialog-Automatisiertes Drucken ist evtl. auch via Autoit möglich, somit kann theoretisch auch Sumatra-PDF aussortiert werden. Ideal wäre aber wohl der Weg über ein Browser Plugin oder wie schon erwähnt ein "eigener Dummy Drucker". Weniger aufwendig sind die Lösungen dann aber auch nicht, da du eher nichts fertiges hierfür finden wirst.

Ganz simpel wäre es evtl. den Standard PDF Betrachter im Browser umzubiegen oder abzuschalten und stattdessen einen Download der Datei zu erzwingen. Dann müsste nur der Downloadordner des Users überwacht werden.