Beiträge von olfibits

Hallo SolemnStrike,

generell hast Du zum Downloaden von Dateien auf einem Webserver die AutoIt-Funktion

InetGet ( "URL", "filename" [, options = 0 [, background = 0]] )

Die Dokumentation dazu findest Du auf https://www.autoitscript.com/a…ocs/functions/InetGet.htm bzw. in der AutoIt-Hilfedatei. Das funktioniert allerdings nur, wenn irgendwo auf Deinem Webserver diese Datei liegt. Verwendest Du z.B. FTP, bräuchtest Du die FTP-Funktionen (siehe https://www.autoitscript.com/a…ns/FTPEx%20Management.htm).

Generell ist es m.E. (natürlich auch mit abhängig vom verwendeten Dateiformat) keine besonders sichere Option, direkt auf einem Webserver die Zugangsdaten zu speichern. (Du kannst Dir das vorstellen, wie wenn auf dem Webserver eine Datei liegt, die sich jeder über einen Download-Link herunterladen könnte. Es ist zwar von außen betrachtet nicht wirklich wahrscheinlich, dass jemand an die Zugangsdaten kommt, aber theoretisch auf jeden Fall denkbar, daher auch nicht sicher.

Es gäbe durchaus bessere Möglichkeiten. Wenn Du sicher bei einer Datei bleiben willst, ist ein FTP-Server mit Verschlüsselung sicherer. Ungeschlagen in Sicherheit und Effizienz wären natürlich Datenbankserver (MySQL, MariaDB etc.), welche aber deutlich mehr Voraussetzungen haben. Dazu wäre es gut zu wissen, welches Format (INI, XML, SQLite3-Datenbank etc.) deine Zugangsdaten haben und vor allem, was ihr Verwendungszweck ist in Bezug auf deine AutoIt-Applikation ist.

Grüße

Florian

Hey, nicht schlecht!

Ein Verbesserungsvorschlag wäre, verwende doch vielleicht besser eine ListView. Das "Skelett" dahinter könnte ja eine INI-Datei in folgendem Format sein:

[Entries]
Number=1

[Entry1]
Name=ProgrammXY
Path=C:\Path\To\Program\XY

Was hältst du davon?

Gar keine schlechte Idee! Fände ich top

Zitat von Neight

& $num & "','" & $aStr[0] & "','" & $aStr[1] & "','" & $aStr[2] _

Nimm einfach anstatt diesem fragwürdigen $num - Konstrukt einfach die 0, also etwa so:

"INSERT INTO tabelle (spalten ...) VALUES (0, '" & $variable & "');"

und so in etwa weiter. Jetzt in etwa klar, funktioniert es jetzt?

Zitat von mep

Da Firmenrechner sind mir leider die Hände gebunden bezüglich AV-Scanner. Daheim seh ich es ähnlich das der Win10 eigene ausreicht und dort auch kein Cloud-Scan.

Bezüglich der Startzeit, ich merk die Verzögerung durch den AV leider schon. Statt 5-10 Sekunden verlängert sich diese Zeit auf 30-45 Sekunden, wobei ich damit leben kann solang es dann schön flüssig läuft. Ist ja nicht so das man ständig andere Projekte öffnet.

Da hätte ich evtl. eine "Notlösung" - wenn ihr nicht ohnehin schon eine vergleichbare Lösung wie VirtualBox installiert habt, kannst du ja evtl. eine Installation von dergleichenen Tools anstoßen und z.B. eine virtuelle Windows 7 oder Windows 10-Maschine installieren. Die ISO-Images kriegt man - zumindest eine updateunberechtigte Version - gerne mal im Internet, auch direkt von Microsoft. Mache ich hin und wieder mal für Debugging mit verschiedenen Darstellungsstilen unter den unterschiedlichen Betriebssystemversionen oder DLL-Kompatiblitätschecks.

@Offtopic

Ich selbst habe seit langem kein AV mehr. Wozu auch? Wenn du vertrauenswürdige Software herunterlädst kannst du dir sicher sein dass sie OK ist. Und meistens verursacht das blöde AV-Programm eh nur Probleme. Ich vergleiche das gerne mal mit einer Alarmanlage. Wozu zuhause oder auch in einer Firma groß Alarm- und Sicherheitsanlagen in allen Bereichen installieren, mit dem Risiko, dass irgendwelche Fehlalarme z.B. durch Mitarbeiter oder unvorsichtige Mitbewohner ausgelöst werden. Und wenn man sich mal am PC nicht sicher ist - entweder den SmartScreen-Filter verwenden bei IE oder vergleichbares Addon im Firefox/Chrome. Und wenn man sich auch dann nicht ganz sicher ist, die heruntergeladene Datei einfach bei VirusTotal.com scannen.

Sicherheitslücken sind immer und überall. Ein AV kann auch MS-interne Sicherheitslücken nicht erkennen und beheben. Und wenn dann durch eine solche Sicherheitslücke rootkitgeschützte Systemdateien ausgetauscht werden, erst recht nicht. Verhindern kann man so etwas natürlich nicht. Aber man sollte den PC mit Sinn und Verstand nutzen. Auf Linux-Servern kommt doch auch sicher keiner an mit hochtechnisierten Sicherheitstools. Höchstens mal mit On-Demand-Scannern, aber keine großen Echtzeitscanner im Hintergrund. Oder mal für Netzwerke (Samba & Co.), aber das war's auch schon.

Es gibt auch Firmen, die selbst in ihren IT-Abteilungen keine AVs installiert haben. Ausführbare Anhänge werden bei denen on-demand gescannt und alle zwei Wochen gibt es einen Vollscan mit Malwarebytes oder ähnlichem. Man kann es auch so machen. Hinzu kommt ja, dass immer wieder von AV-Programmen sonstwas für Nutzerdaten überwacht und gespeichert werden. Die Möglichkeiten haben diese Programme ja. Das wird immer mit "das Programm sorgt ja dafür, dass der Rechner rund läuft" gerechtfertigt. Schlimm ist das.

Sorry für das Offtopic, aber das musste einfach mal sein.

mep

Ladezeiten beim Start sind normal. Aber wenn die AVs anschlagen auch wenn irgendwelche internen DLLs gescannt werden müssen erklärt das einiges.

Hm. Entweder ist es tatsächlich ein AV-Problem was ich definitiv testen würde an deiner Stelle - oder es ist ein Bug im Programm.

Zitat von olfibits

Verschachtelte Tabseiten gingen allerdings in KODA bei mir schon. Wüsste nicht warum das nicht gehen sollte.

Falls aber zwei Tabcontroller nebeneinander gemeint sind - da kann ich es mir schon vorstellen dass das nicht geht. Kann mir aber gerade at-the-moment keine Anwendung vorstellen für die man nebeneinander zwei Tabctrls bräuchte.

Noch ein mal zu dem da ^ ^

Auch verschachtelte gingen selbst in Koda nicht. Tatsächlich eine AutoIt-Limitierung. Mein Fehler, Schande auf mein Haupt

Zu deinem Problem mep könnte ich mir vorstellen dass evtl Programme wie Avira (allg. Antivirensoftware) falls du so was installiert hast stören wegen AV-Scan. Wann genau tritt denn welches Problem auf? Das ist mir jetzt nicht ganz klar. Wenn das FormStudio starten sollte oder beim Erstellen-Dialog? Allerdings kann es auch an jedem x-beliebigem Programmcode liegen. Das kann dir der Entwickler ISI360 dann sicher sagen.

Also über einen anderen Windows-User? Sorry, irgendwie stehe ich gerade auf dem Schlauch

Dann evtl. #requireAdmin, RunAs() oder andere Freigabe.

Kabal1

Bitte mal das ganze Skript, damit man den Fehler vielleicht mal als Forenuser reproduzieren kann.

alpines | AspirinJunkie

Vielleicht sollte man das mal in die Forenregeln aufnehmen. Für mich gibt es nichts Schlimmeres als den Extremfall, nur ein unvollständiges Stück Code und eventuell - hier jetzt nicht - noch eine vollkommen uncheckbare Beschreibung hat und versucht, anhand von dem Code den Bug zu reproduzieren um eine Antwort geben zu können und dann fehlt der halbe Code. Toll

Zitat von Kanashius

Code
runas /user:cybuser@charlottenburg "cybcli.exe"

Wenn du das dann in AutoIT umsetzt mit dir als Nutzer, oder dem Aktuellen Nutzer, sollte es klappen

Sorry für erneuten Post und Kritik an deiner Idee, Kanashius

Aber: Lieber gleich die Built-In-Funktion RunAs verwenden, die unterstützt gleich Benutzername- und Passwortübergabe und das ist dann ein wenig angenehmer als über die CMD herauszufinden warum das Programm evtl. nicht startet. Da kannst du gleich das Makro @Username verwenden und das Passwort weißt Du entweder oder du lässt es dir per InputBox geben - oder du brauchst es gar nicht. keine Ahnung wie das dann ist. Aber wie gesagt - Fragen beantworten, Quellcode posten, erst dann neu testen.

Zitat von Kanashius

Meine Vermutungen wären: Bei den guisetstate() befehlen das fenster mitübergeben, vielleicht wird da was durcheinandergebracht...

Habe ich auch vermutet. Nur habe ich eben getestet ob es daran liegen kann und nacheinander zwei Forms erstellt mit jeweils dem @SW_SHOW Aufruf.

Ändere ich das zweite zu @SW_HIDE kommt das erste trotzdem. Abgesehen davon sagt die AutoIt Hilfe dazu

Zitat

[optional] Windows handle as returned by GUICreate() (default is the previously used window).

was auch erklärt warum es bei mir ging.

Daher: Bitte den kompletten quellcode posten. Danke!

So, hallo zusammen.

Jetzt mal zum Rekapitulieren mcbaldrian, ob ich richtig liege. So ganz klar ist das aus deinen Formulierungen nicht wirklich. Kann sehr gut sein dass ich falsch liege, aber mal sehen.

Du hast einen Dienst. Dieser ist in AutoIt gescriptet und befindet sich als Quellcode in deinem Startpost. Korrekt?

So. Dann wollen wir uns den mal vorknöpfen.

#Include <File.au3>
#include <array.au3>
#include <string.au3>

;INI auslesen die im Scriptverzeichniss liegt
;Forschleife die alle 30 Secunden durchläuft und und die Jobs abarbeitet.###############################################
For $i= 0 to 2880
    if ProcessExists("cceWork.exe") Then ;Der zu überwachende Prozess
            $ProgPath = StringTrimRight(@ScriptDir,"8")
            ShellExecute($ProgPath & "\QueueWatch.exe","","","",@SW_SHOW)
            ;Run("notepad.exe", "" ,@SW_MINIMIZE)
            FileWriteLine(@ScriptDir & "\log.txt", @error & " " &  " " & $ProgPath & "\QueueWatch.exe" & "  " & @CRLF)
    EndIf
    ;Zeitschleife
    Sleep(30100) ; 30,100 Sekunden
    if $i=2879 Then $i=0
Next
;Forschleife die alle 30 Secunden durchläuft und und die Jobs abarbeitet.###############################################

Meiner Meinung nach braucht es keinen einzigen dieser Includes. File.au3 brauchst du nur bei Funktionen die mit _File... beginnen (sogenannte UDFs / benutzerdefinierte Funktionen, die nicht standardmäßig in AutoIt eingebaut sind.) Array.au3 nur bei _Array...-Funktionen, und bei String dasselbe.

So. Dann muss ich erstmal deine seltsam anmutende For-Schleife anmaulen. Anstatt eine For-Schleife zu basteln, die von 0 bis 2880 zählt, und die Zählervariable im For-Block irgendwann wieder auf 0 zurücksetzt... da kannst du gleich von 0 auf 100 zählen und i jedes mal auf 0 setzen Scherz beiseite, im Ernst: Du machst eine While-Schleife. Das Ding soll ja wohl eh in Endlosschleife laufen. Sähe so aus:

While 1
    if ProcessExists("cceWork.exe") Then
            $ProgPath = StringTrimRight(@ScriptDir,"8")
            ShellExecute($ProgPath & "\QueueWatch.exe","","","",@SW_SHOW)
            FileWriteLine(@ScriptDir & "\log.txt", @error & " " &  " " & $ProgPath & "\QueueWatch.exe" & "  " & @CRLF)
    EndIf

    Sleep(30100)
WEnd

So. cceWork.exe scheint also der Prozess zu sein auf dessen Existenz du prüfen willst. Der if-Block wird allerdings nur alle 30 Sekunden ausgeführt. Das bedeutet, dass es rein theoretisch sein könnte, dass folgender Ablauf zustande kommt:

Dienst: Checkt ob Prozess da ist >> ist nicht da >> wartet 30 sekunden

Zeitgleich mit dem Warten ist cceWork mal für 5 Sekunden da und das checkt dein Dienst natürlich nicht. Mit anderen Worten - wirklich sicher ist deine Überprüfung nicht.

Und was die anderen drei Zeilen machen sollen ist mir nur so mittelmäßig klar, was du jetzt da überhaupt splitten kannst.

Warum splittest du rechts 8 Zeichen vom ScriptDir weg? Ich kann nur vermuten - du meinst @ScriptDir enthält den Programmpfad und du willst den Dateinamen weg tun. Sollte das der Fall sein - nein, @ScriptDir ist der Ordner wo sich das Skript/die Exe befindet. Falls nein - dann erkläre doch bitte was du da treiben willst.

Ob die QueueWatch.exe den richtigen Pfad erhält ist schleierhaft. das @SW_SHOW kannst Du dir übrigens klemmen denke ich. Gezeigt wird wenn es eine GUI gibt im Normalfall imme soweit ich weiß. Und warum du in der ZEile 3 im If-Block mit @error ankommst und am Ende noch trotz FileWriteLine ein @CRLF anklemmst... erkläre doch bitte nochmal was genau da ablaufen soll.

Ist es jetzt eigentlich ein Problem der Schreibrechte in die Datenbank oder in das Laufwerk?

Zitat

ich habe eine Access Accdb. Diese leigt im Netzwerklauf. Alle Benutzer haben hier nur Leserechte.

Wenn der User das Script ausführt wird Aufgrund da er nur Leserechte hat nichts in die DB geschrieben.

Dann liegt das Problem meiner Meinung nach nicht daran, dass der Access-Benutzer keine Schreibrechte hat, sondern daran, dass der Windows-Benutzer keine Schreibrechte hat. Liege ich da richtig? Wenn ja, müsste man dem ganzen evtl. ein #RequireAdmin voranstellen oder für das Verzeichnis der Access-Datenbank für alle Benutzer die es ausführen eine Windows-Freigabe erteilen.

Entweder das Motiv Hilfe, eine Nicht-Include-Präprozessordirektive oder Hilfe, irgendwas wird hier versteckt.

Oder: Das ist nicht der Ressourcenstub wie eine gute AutoIt-EXE, aber trotzdem AutoIt. Anmaulen

Ne im Ernst, also die AVs kannst Du eh restlos in die Tonne treten. Habe erst kürzlich ein AutoIt-Prog auf dem Rechner meiner Mutter installiert, insgesamt 9 AutoIt *.exe-Dateien. 3 davon wurden vermüllt. Und eine harmlose sqlite3.dll -> Konsequenz: Avira wurde vermüllt. (Der Gipfel war allerdings, dass er die eigene avscan.dll angemault hat, aber das gehört nicht hierher... habe hier eh schon trotz Haken zu viel Senf abgegeben )

kra88 was mir dazu spontan einfallen würde - evtl. wäre es möglich wenn du multiselect aktiviert hast dass du schaust welche Einträge ausgelesen sind und du schiebst sie nacheinander um einen oder mehrere Plätze nach unten. Kann aber sein dass das gar nicht funktioniert mit dieser UDF oder schlicht und ergreifend Stuss ist. Aber das wäre mir jetzt spontan dazu eingefallen. Aber ansonsten BugFix - super Idee!!

Zitat

Und nein es ist aktuell leider nur 1x pro Gui möglich. (Dies ist aber eine limitierung von AutoIt selbst

Verschachtelte Tabseiten gingen allerdings in KODA bei mir schon. Wüsste nicht warum das nicht gehen sollte.

Falls aber zwei Tabcontroller nebeneinander gemeint sind - da kann ich es mir schon vorstellen dass das nicht geht. Kann mir aber gerade at-the-moment keine Anwendung vorstellen für die man nebeneinander zwei Tabctrls bräuchte.

Es wäre zumindest ein Verfahren, das weniger FPs auslöst.

Zitat von alpines

Trotzdem musst du jede Exe darauf scannen ob es sich um eine AutoIt-Exe handelt, das kostet (wenn man sonst nur die Hash-Signatur vergleicht) viel Zeit.

Naja, es müsste ja theoretisch nur einen funktionierenden Decompiler geben der das AutoIt automatisch dekompiliert oder schimpft dass es keine AutoIt-EXE ist. Für das AV könnte man den Decompiler ja evtl. als DLL ausliefern.

Aber wäre es nicht theoretisch auch kontraproduktiv, nur den Interpreter samt verschlüsseltem Skript (a3x) auszuliefern? Würden die AVs das nicht im Fall von Virenbefall auch irgendwie schnallen?

Zitat von alpines

Dann müsste jede Exe erstmal geprüft werden, ob es sich um ein AutoIt-Kompilat handelt, diese anschließend entschlüsseln und zu guter Letzt das Script analysieren

Gab es nicht mal in älteren Versionen ein Exe2Aut? Wenn es so was auch für AutoIt 3 und aufwärts gibt/gäbe, wäre das doch kein Problem.

Zitat von alpines

Da wird sich jeder AV-Hersteller querstellen um einen Analysator für AutoIt-Skripte zu basteln um zu prüfen ob der Quellcode tatsächlich schädlich ist oder nicht. [...]

Das ist leider richtig, da lässt sich dann außer manuell das zu erledigen wohl leider nichts machen.