ASP.NET Framework aspnet_isapi.dll 'i ISAPI uznatısı olarak uygular.
.aspx, .ascx, .ashx, and .asmx dosya uzantılarını gören IIS isteği doğrudan aspnet_isapi.dll'e yönlendirir.
Temel hali ile ASP.NET konfigurasyon xml dosyası:
<configuration>
<system.web>
<customErrors mode="On" />
<httpRuntime maxRequestLength="51200" />
<authentication mode/>
<identity impersonate="true" />
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration>
ASP.NET çatısı, aynı IIS Worker Process te bile çalışsalar ASP.NET uygulamalarını birbirinden yalıtır.
Master Page tanımı için
@Master direktifini sayfanın üstüne koyarız
<%@ Master %>
<html>
<body>
<form id="frmMain" runat="server">
<table width="100%">
<tr>
<td> <!-- Display Litware Banner -->
<h1>Litware Inc.</h1><hr />
</td>
</tr>
<tr>
<td> <!-- Display Main Body of Page -->
<asp:contentplaceholder id="PlaceHolderMain" runat="server" />
</td>
</tr>
</table>
</form>
</body>
</html>
İçerik sayfası oluşturmak için
@Page direktifi ve içine
MasterPageFile özelliğini tanımlar ve uygun
.master uzantılı dosyayı değer olarak verebilirsiniz.
<%@ Page Language="C#" MasterPageFile="~/default.master" %>
<script runat="server">
protected override void OnLoad(EventArgs e) {
lblDisplay.Text = "Hello World";
}
</script>
<asp:Content ID="main" Runat="Server"
ContentPlaceHolderID="PlaceHolderMain" >
<asp:Label ID="lblDisplay" runat="server" />
</asp:Content>
WSS tarafında MasterPage zaten tanımlı olup biz ContentPage tanımlıyor ve WSS nin masterPage ine referans veriyor olacağız. Bu durumda WSS takımının bizler için hazırladığı PLACEHOLDER ları öğreneceğiz.
Http Request Pipeline 3 değiştirilebilir bileşene sahiptir:
HttpHandler, HttpApplication, HttpModule. Bu bileşenleri kendi bileşenlerimizle değiştirebiliriz.
İstekler(Requests) geldiğinde hepsi bir kuyruğa sıralanır ve bir worker thread atanır. Sonra bu thread sırayla HttpHandler, HttpApplication, HttpModule bileşenlerden geçirir.
HttpHandler sınıfı IHttpHandler arayüzünü uygular. Kendi handlerimizi aşağıdaki gibi oluşturup web.config dosyasına ekleyerek kullanabiliriz.
using System.Web;
public class KendiHendlirim:IHttpHandler
{
public bool IsReusable
{
get { throw new System.NotImplementedException(); }
}
public void ProcessRequest(HttpContext context)
{
throw new System.NotImplementedException();
}
}
HttpApplication sınıfında BeginRequest, AuthenticaRequest, AuthorizeRequest eventlerini geçtikten sonra HttpHandler'a doğru isteği taşırız.
HttpModule benzer şekilde değiştirilebilir componenttır. HttpApplication sınıfı taraından tanımlanan eventlerin handle edilmesiyle değiştirebiliriz. Bu değişiklik, kontrolün HttpHandler sınıfına gönderilmeden önce gerçekleştirilir. Örneğin BeginRequest, AuthenticateRequest, and AuthorizeRequest gibi request-level eventlerini handle etmemiz için özel bir HttpModule component oluşturabiliriz. Bu değişiklikleri IHttpModule arayüzü ile implemente edip HTTP Request Pipeline'a bağlayan bir class yazarak gerçekleştirebiliriz. IHttpModule arayüzünü pipeline'a bağlamamız için web.config'e configuration elementlerini eklememiz gerekir.
Ayrıca HttpApplication'dan farklı olarak birden fazla HttpModule eklenebilir ve machine level'da değiştirilebilir.
Son olarak ASP.NET, HttpContext'i barındıran bir requesti başlatı ve HTTP Request Pipeline'a gönderir. Zaman perspektifinde baktığımızda HttpContext bütün custom kodların execute edilmeden önce oluşturulur. Bu durumda Request, User, ve Response objelerini her zaman programlayabiliriz:
HttpContext currentContext = HttpContext.Current;
string incomingUrl = currentContext.Request.Url;
string currentUser = currentContext.User.Identity.Name;
currentContext.Response.Write("Hello world");
WSS de bir web uygulaması için standart web.config dosyası
<configSections>
<sectionGroup name="SharePoint">
<section name="SafeControls" type="..." />
<section name="RuntimeFilter" type="..." />
<section name="WebPartLimits" type="..." />
<section name="WebPartCache" type="..." />
<section name="WebPartWorkItem" type="..." />
<section name="WebPartControls" type="..." />
<section name="SafeMode" type="..." />
<section name="MergedActions" type="..." />
<section name="PeoplePickerWildcards" type="..." />
</sectionGroup>
</configSections>
<SharePoint>
<SafeMode />
<WebPartLimits />
<WebPartCache />
<WebPartControls />
<SafeControls />
<PeoplePickerWildcards />
<MergedActions />
<BlobCache />
<RuntimeFilter />
</SharePoint>
</configuration>
Microsoft Office SharePoint Designer ile WSS içindeki .aspx ve .master dosyalarımız özelleştirebiliriz. Değiştirilmiş dosyaları kaydettiğimizde, WSS değişimi content veritabanına yazar. Bu sayfayı istemci talep ettiğinde DB den çekilerek gönderilir.
The idea behind a virtual path provider is that it abstracts the details of where page files are stored away from the ASP.NET runtime.
SPVirtualPathProvider gider ASP.NET sayfasını content DB den çekip onu ASP.NET page parsırına gönderir ve oradan gelenide SPPageParserFilter ile DLL dosyasına çevirir. İstenirse bunu web.config de belirtilmesi kaydıyla DLL yapmadan da tutabilir.
SPVirtualPathProvider isteğin ghosted mı unghosted mı olduğuna karar vererek sayfayı content db den çeker.
Ghosted Pages:
UnGhosted Pages:
Virtual Directories
_vit_bin : dll ve .asmx dosyalarımızı barındırır.
_controltemplates : User controllerini barındırır.
_wpresources : Web Part lar tarafından kullanılan resource dosyaları tutar.
_layouts :Application page leri tutar.
Site Pages vs Application Pages
Özelleştirilmiş sayfalar bize büyük bir esneklik sağlıyorken dezavantajları da var. Özelleştirilmiş sayfalar content database'de saklandığı için her unghosted sayfa performansı etkileyecektir. Ayrıca bu sayfalar güvenlik açığına da sebebiyet verecektir. Örneğin admin izni olan bir kullanıcı in-line code ile DB'de tutulan özelleştirilmiş sayfaya saldırıda bulunabilir. Ancak WSS application sayfaları (.aspx) \LAYOUTS isimli bir directory'de tutarak hem özelleştirilmesini önler ve hem de compile edilmesini devre dışı bırakarak güvenliği üst seviyede tutar. Bu sayfaların fiziksel olarak aşağıdaki dizinde tutulmaktadır.
c:\program files\common files\microsoft shared
\web server extensions\12\TEMPLATE\LAYOUTS
Her yeni Web Application oluşturulduğunda \LAYOUTS directory sanal _layouts directoy'sine map edilir. WSS'de farklı siteler açıldığında buralardaki sanal _layouts directory'sine map edilerek de application'lara ulaşılabilir.
Rerefence: Inside Microsoft Windows SharePoint Services 3.0 by Ted Pattisonand, Daniel Larson
