Applikation erfodert lokale Admin Rechte, gibt es Vorgaben von MS?
Hallo Zusammen,
Ich habe gerade eine individuell erstelle Software von einer Firma vor mir, die in unserem Auftrag das Programm entwickelt hat.
Nun, die Software läuft eigentlich soweit gut, aber nur, wenn der angemeldetet User am Clientsystem über lokale Administratoren-Rechte verfügt.
Unsere Sicherheitspolicy sagt aber, dass User nur "Standarduser" bzw. "Power Users" sind.
Ich frage mich nun, ob es von Microsoft einen Design Guide gibt, der z.B. festlegt in welche Bereiche der Registry informationen abgelegt werden dürfen und in welche nicht. Es geht mir darum, dass ichnciht möchte, das zukünftig bei uns hausintern entwickelte Software auch erhöhte Reche benötigt, weil man sich nicht an Vorgaben von Microsoft gehalten hat.
Kann mir jemnd helfen und mir sagen, worauf zu achten ist und wie ich Software entwickele, die nur minimale Rechte des Users benötigt?!
Vielen Dank!!
Was einmal war, wird nie wieder sein...
Servus,
also ich kann dir nicht direkt darauf antworten... aber ich würde einfach mal sagen es kommt immer drauf an was das programm macht damit es admin rechte braucht. wo legt es datein ab und wo schreibt es reg einträge. für den normalen betrieb brauchen, die applikationen die ich kenn, größten teils keine admin rechte ausser VLLT zum installieren.
Wobei ich auch nicht unbedingt glaube das es da ein design pattern gibt...
so far
Smou
private int Main()
{
string programmingSkills = getMySkills("programming")
return = 1;
}
Hi!
Also bei der Installtion benötigte Adminrechte sind kein Problem.
Es geht mir darum, ob Microsoft irgend was bekannt gegeben hat, wo man was speichern darf usw. Also kein Design pattern...
Was einmal war, wird nie wieder sein...
Grundsätzlich sollten alle Programme auch ohne Admin-Rechte laufen. Meiner Ansicht nach ist es eine Designschwäche, wenn eine Applikation ohne Not Admin-Rechte benötigt.
Vorallem bei individuell entwickelter Software finde ich es schwach.
Es liegt an Euch, wie die Vorgaben waren. Ich habe schon für Firmen gearbeitet, die da ganz restriktive Vorstellungen haben und es ging auch -)
Wenn Ihr es entsprechend gefordert habt muss die Firma nachbessern.
Thomas
Es geht mir darum, ob Microsoft irgend was bekannt gegeben hat, wo man was speichern darf usw.
Ob MS da irgendwo ein Guideline zu hat weis ich nicht, aber
- Dateien immer nur in System.Environment.AppData, wenn die Daten lokal für einen Benutzer zugänglich sein sollen, oder System.Environment.CommonAppData, wenn es für alle Benutzer gilt
- Während der Installation (also Admin), bestimmte feste Informationen in HKEY_LOCAL_MACHINE. Danach nur noch und Benutzerspezifisch in HKEY_CURRENT_USER (schreiben). Lesen kann weiterhin von HKLM stattfinden.
Beachten sollte man wirklich, das absolut keine Schreibvorgänge im Anwendungsordner stattfinden, sondern nur in den dafür vorgesehenen Ordnern.
Mehr muss man IMHO nicht beachten. Gerade unter Vista muss dies eingehalten werden, da Vista hier sehr sehr empfindlich ist (was IMHO auch gut so ist).
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)
huhu,
zusätzlich zu Khalids Ausführungen, Kochbuch zur Anwendungskompatibilität. (grad nur kurz gefunden)
Einen "kleinen" Design-Guide gibt es leider nicht. Nur eine Reihe von Vorschlägen und den grossen Design-Guide zum Logo-Test ("Build for Microsoft Windows ..").
Im grossen und ganzen deckt aber ja schon .net mit seinen Mechanismen diese Vorschläge ab. Z.B. Appsettings sind schreibgeschützt, es werden dann nur userspezifische Settings zum User gespeichert. Prinzipiell würde ich immer die Vorgabe machen: "Muss unter Windows XP/Vista als normaler Benutzer funktionieren, ohne dass man Änderungen in den Sicherheitseinstellungen machen muss."
Poweruser existiert imho nicht mehr, der war ein kleiner Administrator mit schreibrechten auf das Programmeverzeichnis.
🙂
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.