Drag & Drop mit aktiven UAC

[Bummi]

@himitsu
ich hatte ihn so verstanden, dass sein Programm nur Probleme hat wenn es mit Administratorrechten ausgeführt wird....

[lbccaleb]

Zitat von himitsu:

Ist das nicht auch ohne UAC verboten?

Fakt ist nunmal, daß Messages von Anwendungen mit niedrigeren Rechten nicht an welche mit höheren Rechten verschickt werden dürfen und daran läßt sich nichts ändern.

1 Antwort später:

Zitat von stOrM:

Naja wenn die Anwendung nicht mit erhöhten Rechten gestartet wird funzt das Drag & Drop wie gewohnt, mit halt nicht...

Da hat wohl Jemand nicht alle Beiträge verarbeitet

[stOrM]

Zitat von Bummi:

@himitsu
ich hatte ihn so verstanden, dass sein Programm nur Probleme hat wenn es mit Administratorrechten ausgeführt wird....

So siehts aus, entweder Drag & Drop oder, mit erhöhten Rechten beides nada

Fakt ist nunmal, daß Messages von Anwendungen mit niedrigeren Rechten nicht an welche mit höheren Rechten verschickt werden dürfen und daran läßt sich nichts ändern.

Hatte ich im ersten Post ja bereits erwähnt das UIPI da zuschlägt, wie auch das MS ja eine Funktion spendiert hat für diesen Fall um trotzdem an gewisse Messages zu kommen, nur klappt das halt nich wenn es sich um Sachen handelt die keine Messages generieren und genau da liegt ja das Problem!

Delphi-Quellcode:

  ChangeWindowMessageFilterEx(Handle, WM_DROPFILES, MSGFLT_ADD, nil);
  ChangeWindowMessageFilterEx(Handle, WM_COPYDATA, MSGFLT_ADD, nil);
  ChangeWindowMessageFilterEx(Handle, WM_COPYGLOBALDATA, MSGFLT_ADD, nil);

Wären lt. diversen MSN Blogs die Nachrichten die man Freischalten müsste.
Was aber keinen Einfluß hat auf:

Delphi-Quellcode:

    fDropHelper : IDropTargetHelper; //A helper that implements details for drag and drop
    function DragEnter(const dataObj: IDataObject; grfKeyState: DWORD;
      pt: TPoint; var dwEffect: DWORD): HResult; stdcall;
    function DragOver(grfKeyState: DWORD; pt: TPoint;
      var dwEffect: DWORD): HResult; reintroduce; stdcall;
    function DragLeave: HResult; stdcall;
    function Drop(const dataObj: IDataObject; grfKeyState: DWORD; pt: TPoint;
      var dwEffect: DWORD): HResult; stdcall;

Denn oben erwähnte Messages werden hierbei nicht generiert.

[rollstuhlfahrer]

Mal ne andere Frage: Was ist, wenn du eine weitere Anwendung erstellst, die mit niedrigeren Rechten auskommt und das OLE-Drag+Drop für dich übernimmt und dann die Ergebnisse per Message/Pipe/sonstwas an das Programm mit höheren Rechten schickt? - Du musst dann quasi nur das Parent deines "kleineren" Programms umstellen und als User sollte man davon nichts mitbekommen.

Bernhard

[Dezipaitor]

Also ich habe mir das mal angesehen.
Die Möglichkeit WM_DROPFILES freizuschalten ist gut möglich und funktioniert auch. Nur darf man kein COM verwenden, wie z.B. IDropTarget.
TJvFilenameEdit und TJvDragDrop funktionierten nach dem ersten Prinzip. TJvDropTarget verwendet COM, daher funktioniert es damit nicht.

Ich habe schon die COM Einstellungen für den Prozess heruntergefahren ohne Erfolg (COM Implementation von IAccessControl). Andersherum kann man den Zugriff für Drag&Drop einschränken, d.h. COM Sicherheit nach oben schrauben.
Da IAccessControl.IsAccessAllowed im ersten Fall nie aufgerufen wird, vermute ich, dass COM schon vorher die Prüfung selbst durchführt und die Nachrichten daher erst garnicht gesendet werden.

Internet Explorer macht es so wie rollstuhlfahrer es beschrieben hat. Es gibt einen Hauptprozess und für jedes Tab einen eigenen Prozess. Wenn man nun eine Datei in den IExplorer fallen lässt, dann wird dies in einem Medium Integrity Level (MIL) Tab geöffnet. Webseiten werden jeweils in einem Low Integrity Level Tab dargestellt.
D.h. der Hauptprozess vom IE übernimmt das Drag&Drop, was ja auch funktioniert, da es im MIL ausgeführt wird. Und die Fenster selbst sind wohl Prozessübergreifend verbunden. Das sieht man im ProcessExplorer, wenn man mal die verschiedenen Bereiche mit dem FindWindow Feature anklickt. Dann sieht man, dass es jedesmal ein anderer Prozess ist.

Mit Spy sollte man keine Nachrichten sehen können, weil bei IDropTarget alles nur noch über COM Callbacks geht.