Geokoordinaten im Entity Framework 5 und SQL Server

Wieder was gelernt. Wenn direkt auf dem SQL-Server eine Punktkoordinate die in Hamburg liegt erzeugt, macht man dies z.B. so:

geography::Point(53.566366364562107, 9.98555839061737, 4326)

Man gibt also der Point-Funktion also erst die Breite dann die Länge. Nutzt man aber die Geofunktionen von Entity Framework 5 (oder neuer) werden die Koordinaten im "Well-known text"-Format angegeben, hier gilt erst der Längengrad, dann der Breitengrad. Beispiel:

DbGeography.FromText("POINT(9.98555839061737 53.566366364562107)", 4326);

IIS Directory Security, und wo kommt die ApplicationPoolIdentity her?

Wenn man manuell ein Verzeichnis anlegt, um dieses später als Root Verzeichnis einer Website im IIS zu nutzen, gibt es ein paar "rechtliche" Dinge zu beachten. Wenn man die Site über den IIS Manager hinzufügt, und aus dem Dialog heraus einen neuen Ordner für die Site erstllen lässt, hat man diese Rechteprobleme üblicherweise nicht, aber auch das ist nicht garantiert.

Nachdem man also das Verzeichnis angelegt hat, sind die Rechte erstmal ziemlich spärlich gesät:

So wird es nach Einrichtung der Site im IIS, beim Aufruf erstmal einen 500er geben, da z.B. die web.config überhaupt nicht gelesen werden kann. Es ist notwendig, ApplicationPool die entsprechenden Rechte zu geben. Der User unter dem das ApplicationPool läuft, ist standardmäßig die ApplicationPoolIdentity. Diese wird man aber vergeblich im Explorer Dialog beim Hinzufügen der Rechte suchen. Es handelt sich um einen "dynamischen" User, dessen Namen man kennen muss. Im Falle des "ASP.NET v4.0" AppPools, heißt der entsprechende User "IIS AppPool\ASP.NET v4.0":

Der Name der AppPoolIdentity lässt sich in der Konsole über

%systemroot%\System32\inetsrv>appcmd.exe list app /site.name:"your.site.name"

abfragen. Auch im IIS Manager kann man sich den Namen anzeigen lassen. Letztendlich sind dann noch die Gruppen IUSR und IIS_IUSRS wichtig, damit der Zugriff auf die Site korrekt funktioniert. Diese kann man bequem über den Explorer Dialog hinzufügen.

Eine sehr gute Beschreibung der verschiedenen relevanten Benutzer und Gruppen findet sich hier: http://stackoverflow.com/questions/5729264/what-are-all-the-user-accounts-for-iis-asp-net-and-how-do-they-differ Dort ist auch der nötige Befehl zum Hinzufügen der Rechte für die ApplicationPoolIdentity nochmal beschrieben.

Mehrere Sites im IIS 7 ohne Wildcard Zertifikat an https binden

Bei der Verwendung eines Nicht-Wildcard SSL Zertifikats im IIS 7, hat man leider keine Möglichkeit das Bindung von einem Hostheader abhängig zu machen. Der Konfigurationsdialog lässt keine entsprechende Eingabe zu:

Man hat aber die Möglichkeit mit einem kleinen Trick, die Eingabe des Hostnamens zuzulassen. Dazu wie folgt vorgehen:

Launch the Microsoft Management Console (MMC)
Select Start –> Run
Type in “MMC” and hit enter
From the console, select File –> Add / Remove Snap-in
Select Certificates from the Add / Remove dialog
Select Computer Account when prompt for which certificates the snap-in will manager.
Select Local Computer when prompted
Click OK to add the Snap-in to the MMC
Locate your SSL certificate
For self-signed (SELFSSL), look in Personal
For installed / purchased, look in the appropriate folder the certificate was originally installed in
Right click on the certificate and select properties
Edit the Friendly Name field so the name starts with an *

Der Dialog in der Management Konsole sieht folgendermaßen aus:

Wenn man anschließend im IIS die https Bindung hinzufügt und das entsprechende Zertifikat auswählt hat man auch die Möglichkeit den Hostnamen einzutragen. Der IIS nimmt durch den * am Anfang des Anzeigenamens des Zertifikats an, dass es sich um ein Wildcard Zertifikat handelt.

Zwar bekommt man im Browser natürlich eine Fehlermeldung, da der Zertifikatname nicht mit dem Servernamen übereinstimmt, aber trotzdem kann man auf diese Weise ein Nicht-Wildcard Zertifikat dazu verwenden, mehrere Sites im IIS 7 an eine IP über https zu binden.