Windows-Dienst, Notification, Zugriff verweigert

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1525712)

Genau andersrum.

Dann erleuchte uns:gruebel:, anstatt noch mehr heiße Luft zu produzieren!

Wie geht es dann richtig?

[QuickAndDirty]

Ich bin zwar nicht Himitsu...aber vielleicht denkt er an sowas:
In Windwows 11 gibts ein Windows Notification Center ... ich denke(Ich weiß es nicht!!!) da haben sie endlich mal eine Lösung geschaffen die vergleichbar mit Android oder IOS ist, wo man Pushnotofications auf den Desktop zaubern kann?

Aber auf älteren Windosen muss man mit der Systray weiter machen...

[Delrabe]

Hallo,

danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

Hab ich doch beschrieben?
Kannst'e lesen?

* du bist dafür, dass jeder eine App unsichtbart oder im Tray laufen lässt, selbst wenn die meistens nicht genutzt wird

* ich bin dafür, dass man diese "permanenten" Nachrichten-Apps abschafft und stattdessen der Dienst im Falle des Anzeigewillens den Prozess zum Anzeigen im aktiven Kontext vorübergehend startet,
damit eben nicht sinnlos tausende Anwendungen aktiv sein müssen.

Und ja, das NotificationCenter ist auch nett.
OK, die Komponente von Embarcadero ist schrott, aber per se muß das Programm nicht dauerhaft laufen, nach der Anzeige dort. Wenn sich die Anwendung/Komponente richtig mit der Notification verbunden hätte, würde Windows unser Programm wieder starten, wenn man auf die Notification klickt und das eigene Programm schon wieder weg war.

[Delrabe]

Hallo,

@himitsu: unabhängig davon, was gut oder schlecht ist, die Hauptfrage ist, was geht und was geht nicht. Bei der Version "Dienst startet Notify.App" besteht das Problem, dies auch wirklich durchzuführen. Wie bereits beschrieben, der Dienst verschafft sich das "Token" des aktuellen Users/Contextes und versucht dann die NotifyApp über "CreateProcessAsUser" zu starten. Dies schlägt leider fehl mit einer Meldung über fehlende Rechte. Möglicherweise muß man bei diesem Aufruf noch zusätzliche Parameter einbauen (SecurityAttributes, ThreadAttributes, Environment), aber da bräuchte ich Hinweise, wie genau das geht. Ich habe im Netz schon viel dazu gelesen, aber keine funktionierenden präzisen Hinweise gefunden.

Es wird im übrigen auch "CreateProcessWithLogonW" vorgeschlagen, aber da weiß ich nicht, wie das "gehen" soll, da man ja das Passwort nicht kennt.

[Delrabe]

Hallo,

irgendwie ging meine Antwort von vor einer Stunde verlustig. Daher noch einmal ein Versuch.

Danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

[ups]

[Sinspin]

Der Name einer Named Pipe ist beiden Programmen bekannt. Über den Name kommt die Verbindung zustande. Der Dienst muss die Named Pipe erzeugen und ihre Rechte anpassen, sonst ist sie außerhalb der des Dienst Desktops sichtbar/erreichbar.
Ich verwende eine Komponente von NSoftware, die den Aufwand für die Nutzung etwas reduziert. Da gibt es sicherlich auch noch andere Lösungen. Oder eben den direkten weg.

Das ist halt immer die Frage, reicht eine Anwendung via Autostart? Oder ist es wichtig das auch in Fällen in denen kein Nutzer angemeldet ist, aber es Zeit wird die Aufgabe zu erledigen, die Aufgabe erledigt werden kann. Dienste laufen mit dem Rechner, Anwenderprogramme erst mit Nutzeranmeldung.

[Delrabe]

Hallo Sinspin,

in meinem Fall würde die Autostart-Version reichen. Sie muß nur funktionieren, insbesondere wenn der angemeldete User nicht über die notwendigen Rechte (z.B. Download) verfügt.

[himitsu]

@Delrabe
Dass es geht, beweisen ja mehrere Programme, welche die NotifyApp aus dem Server starten.

Auch kann man im Server einen neuen Thread erstellen, ihn in einen anderen Kontext verschieben und von dort aus auf den Nutzerdesktop zugreifen.
z.B. TeamViewer soll das intern tun, um z.B. die UAC-Passorteingabe anzeigen zu können.