Ich meinte nicht anstelle, sondern eher als alternative.
Ich gehoere zwar auch zu den leuten die Server mit PHP sowie MySQL besitzen,
aber ich habe (und bin sicher nicht der einzige) auch Server auf denen nur IIS läuft (Und auf solchen Maschinen PHP einzurichten find ich is der Horror :P).
Es ist nicht so das ich etwas gegen PHP oder so habe, aber ich hab zb in meinen Internen netzwerk nur IIS.
Das Admintool koennte ja automatisch erkennen ob es sich um einen Win oder *nix Server handelt und je nachdem entsprechende Dateien verwenden (bzw je nach Benutzerwahl)
Also in dem Punkt muss ich dir Recht geben... PHP auf einem IIS einzurichten... Himmel... das musste ich zweimal hier in der Firma machen und ich saß jeweils n halben Tag dran. Müsst ich mir mal anschauen wieviel Zeit das genau in Anspruch nehmen würde.
Übrigens kommt in der nächsten Version nun auch endlich die Möglichkeit die Nachricht am Ende des Updatevorgangs zu unterdrücken. So muss nicht mehr mit OK bestätigt werden.
Ich bin nun dabei dieses Problem mit den Adminrechten zu lösen.
Schritt 1 ist mal gelöst: es ist möglich - wenn man das will - die Benutzerinformationen unter dessen Rechten die updater.exe ausgeführt werden soll direkt anzugeben. Das bedeutet der Anwender müsste nichts mehr bestätigen und das Update würde durchlaufen.
Ich konnte das auch unter XP erfolgreich testen. Der Benutzer hatte eingeschränkte Rechte, konnte das Update aber dennoch durchführen und im Programmeordner wurden die entsprechenden Dateien angelegt. Diese konnten im Anschluss aber auch nicht mehr vom Benutzer gelöscht werden, da dieser ja keine Rechte dazu hatte. Ich denke das ist vom Verhalten her korrekt.
Jetzt kommt aber eben noch der andere Punkt: die Kontoinformationen sollen ja nicht unbedingt schon mitgegeben werden, bzw. können sie ja auch im Normalfall gar nicht mitgegeben werden.
Wie ist in so einem Falle vorzugehen? Kann mir an dem Punkt jemand helfen wie ich eine Anwendung starte, so dass daraufhin diese Meldung aufpoppt und der Benutzer aufgefordert wird entsprechende Kontoinformationen anzugeben?
Ich denke dabei an diese Meldung:
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von EvilMM am .
Hm, ich denke eher, dass dieses Fenster eben gerade nicht aufpoppen soll. Der stinknormale User soll ein Update ausführen können, ohne dabei selbst einen Admin Account angeben zu müssen. Das ist ja Sinn der Sache, denn sonst könnte er auch gleich sein Programm mit Adminrechten updaten.
Ich würde sagen, dass eben gerade diese Credentials in KUpadter_Admin Konsole definiert werden sollten, und bei Bedarf eines Updates werden diese Credentials übernommen.
Das ist ja genau das, was bei der Impersonifizierung passiert. Ich hatte dir diesbezüglich ja mal eine Klasse geschickt. Du startest also deine Update.exe ganz normal, mit normalen Rechten (das ist wichtig, denn sonst wird nach dem Update, wenn eine andere EXE automatisch gestartet werden soll, diese auch mit Admin Rechten gestartet. Das ist nicht gewollt).
Und sobald deine Update.exe zu löschen und kopieren beginnt, machst du eine Impersonifizierung. Die Credentials dazu (Domainname, Login und Password) müssen natürlich bekannt sein, und irgendwie verschlüsselt im XML Konfigurationsfile definiert sein. Nachdem du dich impersonifiziert hast, hat dein Programm diese Rechte, obwohl es noch im Taskmanager unter dem normalen User angezeigt wird. Nach dem Kopieren, also kurz bevor du die nach dem Update gewünschten Programme starten willst, hebst du die Impersonifizierung auf. Dadurch starten die Programme dann wieder als normaler User.
Ja das ist ja schon klar. Aber das Problem ist doch, dass ich doch hier noch nicht die Konteninformationen eines x-beliebigen Benutzers da draußen kenne, also muss ich ihn zu Laufzeit auffordern Benutzer und Passwort einzugeben.
Ich geh von einer anderen Grundlage aus, dass sich nämlich die PCs, die ein Update aufspielen sollen, alle in der gleichen Windowsdomäne befinden. Da kann ich dann sehr wohl einen festen Domain User definieren, der dann lokal die nötigen Rechte besitzt.
Wenn jedoch nicht in einer Domäne, so sind diese Informationen natürlich nur auf dem Host definiert. Hmm. In dem Fall bleibt wohl wirklich nix anderes übrig, als nach einem User ze fragen, der die notwendigen Rechte besitzt. Ob das der Windowsdialog ist oder ein anderer spielt ja da keine Rolle, oder ?
Mal so rein prinzipiell könnte ich mir folgendes Scenario vorstellen:
1. Sind Credentials in der XML Datei definiert, dann verwende die, ansonsten versuche das Update mit dem eingeloggten User
2. Schlägt das Update mit dem eingeloggten User fehl wegen mangelnder Rechte, so frage nach einem anderen Account, impersonifiziere, und versuchs nochmal. Schlägts wieder fehl, nochmals fragen...
Exakt. Genauso stell ich mir das auch vor.
Und genau diese Aufforderung benötige ich jetzt nämlich. Und da komm ich grad nicht weiter. Weil genau da stell ich mir dann vor, dass solch ein Dialog wie oben erscheint.
Von den Informationen her benötigst du ja nur Login, Passwort und eventuell Domain. Du kannst dir doch aber leicht einen solchen Dialog basteln, der genau diese Informationen abfragt. Damit kannst du ja dann versuchen, dich zu impersonifizieren... Wenn du möchtest, kann ich dir diesen Dialog erstellen.
Richtig, das müsste reichen an der Stelle.
Wenn du das machen könntest wäre das natürlich klasse. Dann könnte ich mich an der Stelle dann schonmal auf das korrekte Impersonifizieren konzentrieren.
Kein Problem... Wird zwar heut nix mehr, aber morgen werd ich mir das zur Brust nehmen... Ich werde dazu eine eigene Klasse definieren, welche die Credentials beinhalten wird, und die du nutzen kannst, um zu impersonifizieren. Ich denke das Passwort selbst werde ich wohl in einem SecureString ablegen, damit das auch alles halbwegs sicher ist. Der Dialog wird dir wohl ein DialogResult liefern, das du dann auswerten kannst...
Ist das so ok. Ich denke es macht keinen Sinn, wenn ich die Impersonifizierung selbst vornehme, da du dies ja eh machen musst, wenn in deinem XML File die UserCredentials definiert sind. Oder ?
Man kann bei der Erzeugung eines Updatepaketes die Konto-Daten für die Impersonifikation angeben, wenn diese schon vorher bekannt sind.
Tritt beim Update ein Fehler auf (Dateien können nicht gelöscht oder geschrieben werden) wird - falls Informationen angegeben wurde - per Impersonifikation der Benutzer kurzfristig gewechselt. Daraufhin wird erneut versucht die Datei zu löschen oder zu kopieren. Klappt das wieder nicht bekommt der Anwender eine Meldung mit einem entsprechenden Hinweis. Er hätte dann die Möglichkeit das Update abzubrechen, die Aktion zu wiederholen oder dann eben die Kontoinformationen manuell anzugeben.
Ich glaube das müsste dann in dieser Weise ok sein oder?
Das denke ich ist ok. Und wenn keine Credentials schon bei der Erstellung des Updates angegeben wurden, geh ich davon aus, dass gleich das Abfragefenster kommt, wenn eine Datei nicht gelöscht oder kopiert werden kann.
Ich bin heut mittag noch weg, aber werde mich dann im frühen Abend wohl um den Dialog kümmern.
Also Impersonifikation bezeichnet genau das, ja. Du gibts dir kurzzeitig die nötigen Rechte, und swappst dann wieder zu dem ursprünglichen User zurück. Das ist also in der Tat etwas anderes, als ein Programm von vorne heraus unter einem anderen Benutzer zu starten (RunAs)...
Noch was am Rande: Wenn du dich impersonifizierst, und dann eine andere Anwendung normal startest, so hatte diese Anwendung NICHT die Rechte des impersonifizierten Users, sondern startet ganz normal.
Ich hab nun mal ein kleines Szenario nachgestellt.
Der Benutzer befindet sich auf einem XP-Rechner mit eingeschränkten Benutzerrechten.
Es sind keine Impersonifikationsinformationen hinterlegt. Das Update wird durchgeführt und versucht Dateien zu löschen.
17:09:40 [Main][deleteFiles] Delete old files...
17:09:40 [Main][deleteFiles] -> Delete C:\Programme\Testapplikation\Update\5239-sd.jpg...
17:09:40 [Main][deleteFiles] - 1. try
17:09:40 [Main][deleteFiles] - Could not delete file
17:09:40 [Main][impersonifyUser] Try Impersonification
17:09:40 [Main][impersonifyUser] -> No Informations
17:09:40 [Main][deleteFiles] - 2. try
17:09:40 [Main][deleteFiles] - Could not delete file
17:09:44 [Main][deleteFiles] - 3. try
17:09:44 [Main][deleteFiles] - Could not delete file
17:09:45 [Main][deleteFiles] - 4. try
17:09:45 [Main][deleteFiles] - Could not delete file
Nach dem ersten Versuch wird versucht dem Benutzer mehr Rechte zugeben, es sind aber keine Informationen hinterlegt. Jetzt bekommt der Benutzer einen Dialog angezeigt der derzeit noch so aussieht:
Er hat nun mehrmals auf "Wiederholen" geklickt, daher oben die mehreren Versuche.
Nun der zeite Fall:
Es wurden Impersonifikationsinformationen hinterlegt. Diese Informationen können natürlich auch nachträglich noch geändert werden, es muss ja nur das Updatepaket bearbeitet werden.
Ich denke, das sollte so hinkommen. Vielleicht rennst du in ein Problem, wenn ein File aus irgendeinem anderen Grund nicht gelöscht werden kann (in use o.ä.). Zur Zeit gehst du in dem Fall natürlich davon aus, dass es an fehlenden Berechtigungen fehltm und versuchst zu impersonifizieren. Wie sollst du auch wissen, warum ein File nicht gelöscht werden kann... Ein Workaround dazu hab ich zur Zeit auch nicht. Ein Flag im Update Paket, z.B. always require Administrative priviledges, könnte vielleicht helfen, denn schlägt dann ein Löschen fehl, dann liegt es nicht an den fehlenden Rechten sondern an was anderem?? Aber ich denke mal, man kann auch erstmal ohne sowas arbeiten.
Ich werde wohl erst morgen dazu kommen, den Dialog zu erstellen. Krieg noch unverhofft Besuch gleich, und da macht es sich nicht gut, wenn ich mich dann vor mein VS hocke und Dialoge programmiere... Hoffe das hat also noch Zeit bis morgen... Wird aber nicht vergessen.
Ja an der Stelle muss ich mir das mal überlegen.
Ich werd mal versuchen rauszufinden wie man ermitteln kann ob eine Datei gerade in Benutzung ist.
Der Dialog hat selbstverständlich noch Zeit. Habe an der Anwendung sowieso noch andere Sachen zu schaffen. Somit macht das nichts wenns heute nichts mehr wird.
Ich hab mir das nochmal alles überlegt wie es wohl optimal wäre.
Möglich sollte von seiten der Updatepaket-Konfiguration sein entweder direkt die Credentials für die Impersonifikation zu vergeben oder alternativ auch direkt den Admin-Modus vorauszusetzen. Im zweiten Falle führe ich den Prozess updater.exe auch direkt mit requireAdmin aus.
Sollte beides nicht gewählt sein würde im Falle eines Fehlers beim Löschen oder beim Schreiben einer Datei der oben gezeigte Dialog erscheinen und dort müsste dann eben noch die Möglichkeit rein das Benutzerkonto zu wechseln.
