Serverfehler in der Anwendung ASP.net

[eddie11]

Guten Morgen allerseits

ich benutze Tubo Delphi Explorer .Net. Bisher hatte ich meine Projekte immer lokal auf meinem Rechner unter \eigene Dateien\Borland Studio Projekte\ - da hat alles funtioniert. Jetzt musste ich den Rechner neu aufsetzen und habe die Projekte im Netzwerk abgelegt. Den Standard-Pfad habe ich in den Optionen auf diesen Netzwerkpfad umgeleitet. Die IDE funzt einwandfrei, Compilieren und Erzeugen ebenfalls. Beim Ausführen gibt es dann die folgende Fehlermeldung im Browser:

Delphi-Quellcode:

Serverfehler in der Anwendung '/TestProjekt'.
--------------------------------------------------------------------------------

Parserfehler 
Beschreibung: Beim Verarbeiten einer Resource, die für diese Anforderung erforderlich ist, ist ein Fehler aufgetreten. Überprüfen Sie folgende Fehlerinformationen und ändern Sie die Quelldatei entsprechend. 

Parser-Fehlermeldung: Der Typ 'Global.TGlobal' konnte nicht geladen werden.

Quellfehler: 


Zeile 1:  <%@ Application Codebehind="Global.pas" Inherits="Global.TGlobal" %>
Zeile 2:  

 

Quelldatei: \\fs1\navi\Allgemein\Delphi Projekte Net\TestProjekt\global.asax    Zeile: 1 


--------------------------------------------------------------------------------
Versionsinformationen: Microsoft .NET Framework Version:1.1.4322.2443; ASP.NET-Version:1.1.4322.2443

Das ist unabhängig davon, ob ich den IIs oder Cassini benutze. Das passiert sowohl bie alten Projekten, als auch bei einem komplett neu erstellten Projekt. Übertrage ich so ein Projekt auf meinen lokalen PC in das Standard-Verzeichnis, dann geht es. Die Rechte auf den Netzwerkpfad habe ich schon auf "jeder darf alles" gesetzt, daran scheint es also nicht zu liegen. Irgendwo scheint es noch einen Verweis auf den lokalen Rechner zu geben - aber wo?

Vielen Dank für Eure Hilfe...

[Mavarik]

Liegt Dein Server root auch bei
\\fs1\navi\Allgemein\Delphi Projekte Net\TestProjekt\

Liegt die dll auch in
\\fs1\navi\Allgemein\Delphi Projekte Net\TestProjekt\bin

Mavarik

[Phoenix]

Zitat:

Zitat von eddie11

und habe die Projekte im Netzwerk abgelegt.

Das ist das Problem.
ASP.NET Anwendungen laufen immer in medium-Trust Umgebungen. Um Assemblies aus dem Netzwerk auszuführen benötigst Du aber Full-Trust. Das sind Konzepte aus der .NET Code Access Security.

Ich habe keine Ahnung, wie man Webanwendungen auf Full Trust umstellen kann (das sollte man um Himmels willen auch eigentlich nie machen). Ich rate Dir, die Assemblies einfach lokal auf den ausführenden Rechner zu packen. Das ist von der CAS her erlaubt und beim Einsetzen auf dem Webserver die Anwendung eh lokal installiert.

[sniper_w]

Zitat:

Zitat von Phoenix

(das sollte man um Himmels willen auch eigentlich nie machen)

Und wieso ist das so?
Normalerweise wird ASP.NET Hostprocess impersonated, d.h. unter dem für die Webseite voreingestelltem Benutzerkonto ausgefürt. Das hat die Folge, dass man die Berechtigungen über das Dateisystem abbilden kann. Die Berechtigungen sind im normal Fall so eingeschränkt, dass man mit seiner Applikation nirgendwo schreiben kann ausser explizit erlaubt.Lesen geht nur im ~ (Applikationrootordener) und darunter.
Verpasse ich etwas?

[Phoenix]

Zitat:

Zitat von sniper_w

Und wieso ist das so?
Normalerweise wird ASP.NET Hostprocess impersonated, d.h. unter dem für die Webseite voreingestelltem Benutzerkonto ausgefürt. Das hat die Folge, dass man die Berechtigungen über das Dateisystem abbilden kann. Die Berechtigungen sind im normal Fall so eingeschränkt, dass man mit seiner Applikation nirgendwo schreiben kann ausser explizit erlaubt.Lesen geht nur im ~ (Applikationrootordener) und darunter.
Verpasse ich etwas?

Jain. ASP.NET Prozesse laufen entweder unter einem fest eingestellten Konto, ODER mittels impersonation als der (System-)User, der sich an der Webanwendung angemeldet hat (Sei es Basic, NTLM oder auch Windows Forms Authentication).

Aber es geht nicht nur um Filesystemberechtigungen.

Full trust erlaubt es einer Webanwendung z.B. auch, dynamischen Code zu erzeugen.
Ein Angreifer hätte also rein theoretisch die Möglichkeit Code zu generieren der (möglicherweise unter Ausnutzung anderer Sicherheitlücken) den Prozess erneut impersoniert und zwar z.B. mit dem System-Account. Und dann gute Nacht bis um 12, denn dann ist alles möglich.

Selbst wenn der Prozess eingeschränkt ist: Full trust ist eigentlich generell eine ganz schlechte Idee.

[eddie11]

vielen Dank für die Antworten - leider nicht so recht befriedigend :-( - aber das liegt wohl in der Natur der Sache.

Der Grund warum die Projekte jetzt auf dem Server liegen ist auch, dass auf diese Art auch mein Kollege auf die Sourcen zugreifen kann. Nun werden wir das wohl wieder jeder lokal installieren und dann nur ins Netz sichern - beide gleichzeitig arbeiten ohnehin nie an dem gleichen Projekt.

[Phoenix]

Zitat:

Zitat von eddie11

Der Grund warum die Projekte jetzt auf dem Server liegen ist auch, dass auf diese Art auch mein Kollege auf die Sourcen zugreifen kann. Nun werden wir das wohl wieder jeder lokal installieren und dann nur ins Netz sichern - beide gleichzeitig arbeiten ohnehin nie an dem gleichen Projekt.

VisualSVN Server auf dem Server installieren (kostenlos). TortoiseSVN auf den Clients installieren (kostenlos). Über eine gescheite Quellcodeversionierung freuen die man auf dem Server ganz einfach wegsichern kann.