jquery autocomplete cache problem

You have to make a little changes in autocomplete.js.

Search for "*if (data && data.length*)" condition which is inside "request"
function. Add this code before the *if * condition

if(data)
data.length=0;

http://www.mail-archive.com/jquery-en@googlegroups.com/msg80627.html

Cannot remove an entity that has not been attached

You are using two different context. One retrieves it, the second tries to delete it.

http://forums.asp.net/p/1475529/3430701.aspx#3430701

adding css file dynamically

protected void Page_Init(object sender, EventArgs e)
{
// Define an HtmlLink control.
HtmlLink myHtmlLink = new HtmlLink();
myHtmlLink.Href = "~/StyleSheet.css";
myHtmlLink.Attributes.Add("rel", "stylesheet");
myHtmlLink.Attributes.Add("type", "text/css");

// Add the HtmlLink to the Head section of the page.
Page.Header.Controls.Add(myHtmlLink);
}

http://www.aspdotnetfaq.com/Faq/How-do-I-dynamically-add-CSS-file-for-ASP-NET-ASPX-page.aspx

webbrowser documentcompleted is raised more than once

çözüm:
webbrowser'ın readystate özelliği complete ise işlem yap.

private void webBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
    if (webBrowser1.ReadyState == WebBrowserReadyState.Complete)
    {
         // do something
    }
}

not: saatlerce bu sorunla uğraştım. algoritmamda bir hata olduğunu düşünüyordum. sonra "acaba bu bir bug olabilir mi" diye google'a danıştım ve aramam sadece ve sadece "webbrowser documentcompleted" sözcüklerinden oluşuyordu. çıkan sonuçlardan dördüncüsünde yanıtı buldum. ve bu durum bana şunu düşündürdü:
eğer msdn'den webbrowser kontrolünü veya onun documentcompleted event'ini incelemiş olsaydım, bu bilgiye zaten ulaşmış olacaktım. hazıra konmaya çalışmak işte bazen tam tersine böyle zaman kayıplarına yol açıyor. bu da bana ders olsun =/

not2: webBrowser1_DocumentCompleted event'inde exception oluştuğunda uyarı verilmiyor. try catch ile kendin yakalamalısın.

URL Escape Characters

http://community.contractwebdevelopment.com/url-escape-characters

http://www.blooberry.com/indexdot/html/topics/urlencoding.htm

linq : insert into middle table

var band = new Band {Title = bandName};
if (_db.Bands.Where(b => b.Title == bandName).Count() == 0)
{
_db.Bands.InsertOnSubmit(band);
_db.SubmitChanges();
}

1. sadece band_genre tablosuna kayıt yapar:

var bandGenre = new Band_Genre();
bandGenre.BandId = band.BandId;
bandGenre.GenreId = _currentGenre.GenreId;
_db.Band_Genres.InsertOnSubmit(bandGenre);
_db.SubmitChanges();


2. band_genre, band ve genre tablolarının tümüne kayıt yapar. (yani aynı band ve genre birden fazla kez eklenebilir.):

var bandGenre = new Band_Genre {Band = band, Genre = _currentGenre};
_db.Band_Genres.InsertOnSubmit(bandGenre);
_db.SubmitChanges();

related jquery autocomplete controls

Error Handling in Asp.Net

All applications should have error handling. This we all know. We can't always be notified of an unhandled error (and usually aren't) when one occurs on a client's machine. The advantage we have on the Web is that we can always be notified when an unhandled error occurs. With the advent of ASP.NET, there are some great new ways to handle errors. There are some differences in .NET in not only how to handle the error, but how the information is provided to you. For example, classic ASP uses Server.GetLastError to return an ASPError object. You can and should still use Server.GetLastError in .NET, but this now returns a type System.Exception. I must give Microsoft credit for making almost everything consistent in .NET, which is quite a welcome change.
download source code
The Problem
Errors will occur in our applications. We try to trap for most errors using try-catch blocks (or the only possibility in tradional ASP 'on error resume next'); however, we usually don't cover every possible exception. What happens when an unhandled error occurs? Usually the user is brought to IIS's default error pages (usually located in c:\winnt\help\iishelp\common). The downsides are you have no idea when this occurs and the page doesn't have your site's look and feel. Errors are a development fact, but we strive to eliminate or handle them gracefully. With this in mind, we need to know:

1. When an error occurs
2. Where it occurred
3. What the error is

Having a central location such as the event log, database or some other log file to log errors is essential for debugging this problem later (I call this forensics debugging).
IIS provides great error-handling capabilities (see my article at http://www.15seconds.com/issue/020821.htm). There are some problems with these though. Sometimes we know an error will occur, and we can't always trap for it in a nice way without overriding the site's (done in the IIS custom errors Page; see the article mentioned above) default error redirection page. For example, upon access to a resource that requires authentication, we may need to redirect to an application's login page. Also, a very common problem exists with Web hosts. If you have a hosted Web site, you usually have no control over its IIS configuration. Thus, setting up custom error pages can be next to impossible in traditional ASP. This is elimiated with ASP.NET, as you will learn as you read on.
The Solution
For such a list of problems, the solution is actually pretty simple. There are three places in ASP.NET to define what happens to these unhandled errors.

1. In the web.config file's customErrors section.
2. In the global.asax file's Application_Error sub.
3. On the aspx or associated codebehind page in the Page_Error sub.

The actual order of error handling events is as follows:

1. On the Page itself, in the Page_Error sub (this is default, you can name it anything because it specificed Handles MyBase.Error)
2. The global.asax Application_Error sub
3. The web.config file

Note: To cancel the bubbling up of the error at anytime for the Page_Error or Application_Error, call the "Server.ClearError" function in your sub. Each method has its own uses, as I will explain.
When an exception occurs in your application, it should be an object inherited from type System.Exception, and as such will have the following public members:

HelpLink	Gets or sets a link to the help file associated with this exception.
InnerException	Gets the Exception instance that caused the current exception.
Message	Gets a message that describes the current exception.
Source	Gets or sets the name of the application or the object that causes the error.
StackTrace	Gets a string representation of the frames on the call stack at the time the current exception was thrown.
TargetSite	Gets the method that throws the current exception.

Using the Page_Error or OnError sub
The first line of defense in error handling happens at the page level. You can override the MyBase.Error sub as such: (Visual Studio will complete the code if you click either the Overrides or BaseClass events in the editor). The two functions you can use (one or the other, both will not work as only one will get called)

    Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs) 
Handles MyBase.Error
    
    End Sub

Or you can use this one:

  
 Protected Overrides Sub OnError(ByVal e As System.EventArgs)

    End Sub

Handling errors in these subs is a simple process. Just call Server.GetLastError to return the error. If you want to redirect to a specific page here you can just call Response.Redirect ("HandleError.aspx") or whatever your page may be. This method of handling errors is good for several reasons.

1. If you need to override the Application_Error or the customErrors setup in the web.config file
2. If each page must implement it's own error handling If you need to log specific information and then carry on, just code for your logging or whatever here, and that is all. If you need to cancel the error processing here (so it doesn't go to the Application_Error or customErrors) simply call Server.ClearError in this sub.

Using the global.asax File
The global.asax file contains the next line of defense against errors. When an error occurs, the Application_Error sub is called. This location happens to be my favorite place to log errors because it is the most functional. For most of my applications in .NET, I don't handle too many custom errors at the page level. I handle them at the application level. The only two locations that actually give you access to Server.GetLastError are in the Page_Error and Application_Error subs.
After the Page_Error is called, the Application_Error sub is called. Here you can also log the error and redirect to another page. I won't explain anything else about it because it is basically the same as the Page_Error but happens to be at the application level rather than the page level.
Using the web.config File
The customErrors element of the web.config file is the last line of defense against an unhandled error. If you have other error handlers in place, like the Application_Error of Page_Error subs, these will get called first. Provided they don't do a Response.Redirect or a Server.ClearError, you should be brought to the page(s) defined in the web.config. In the web.config file, you can handle specific error codes (500, 404, etc), or you can use one page to handle all errors. This is a major difference between this method and the others (although you can emulate this by doing various Response.Redirects using the other methods). Open up your web.config file. The customErrors section uses this format:

Here is some important information about the "mode" attribute:"On" specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.
"Off" specifies that custom errors are disabled. This allows display of detailed errors.
"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.
By default, the section looks like this when you create a Web application.

This will show a generic page to users. To redirect it to one of your own pages, you would change it to this:

Now all errors that occur will be brought to the error.htm page.To handle specific errors, and redirect to the error page for everything else you can specify the error code you want specially handled like so:

There is a problem here with this solution. Once the redirect is done, your error information is no longer available on the redirected page. This is because IIS (via the .net framework) performs a plain old GET request to the error page and does not do a "Server.Transfer" like the built-in IIS error handling does.The only information available to you at this time is the URL that caused this error to be raised. This is located on the querystring as "aspxerrorpath": http://localhost/ErrorHandling/error500.aspx?aspxerrorpath=/ErrorHandling/WebForm1.aspx. The only places this information is available is the two methods described above.
Another interesting point about the above customErrors element is that you can specify different error pages for different subdirectories.
For this example, let's say you have a directory named "Customers" off of your root directory that contains a branding specific for logged in customers but is not in its own application. As such you want to define a different set of pages for errors. Please note that these pages specified in the "redirect" attribute are relative to the "Customers" subdirectory and not the root path of your site. I have also included a security rule which says only MYDOMAIN\Customers can access these files. You can define rules for these errors in the web.config file:

   
      ...
      ...
   

   
   
      
   
  
  
  
  
        
 
  
  
 
      
   

Note: One thing I found in development is there seems to be an inheritance order for these errors. What I mean by this is if you have a 500 error defined for the root site, but none defined for the customers directory, but you DO have a defaultRedirect set for the customer directory, the 500 handler defined at the root level will be called. So if a parent directory has a handler.Using the Code
I have created an application with settings, so you can get an idea of how to configure your code. In the zip file there is a solution containing two projects.
The first is a Web project that has some buttons to cause different errors. It also shows an example of handling the error through the page, global.asax, and web.config file. There will also be a DotNetErrorLog.sql you can run in query analyzer to create a database (and user) to start logging errors ASAP.
You will notice in my web.config I have the following:

This is where I keep specific settings for an application. You do not have to worry about keeping it in the registry, and this is great for moving your applications between development, integration, and production environments (if you are blessed with that). For better security, you can incorporate the encryption classes in .NET to encrypt the database connection info and store that information in the web.config rather than the plain text connectstring, but that obviously isn't the purpose of this article. The settings pretty much are as follows:

1. To log to a db:
   1. ErrorLoggingLogToDB - Set to "True" to tell the app you want to log info into the db
   2. ErrorLoggingConnectString - The connect string to connect to the database to store errors
2. To log to the event log:
   1. ErrorLoggingLogToEventLog - Set to "True" to tell the app you want to log error information to the event log
   2. ErrorLoggingEventLogType - The name of the event log to log to (ex. System, Application, etc etc.). You can even create your own log just for web errors too, which could be ideal for large sites!
3. To log to a text file:
   1. ErrorLoggingLogToFile - Set to "True" to tell the app you want to log info to a text file
   2. ErrorLoggingLogFile - The path of the file to log errors to

Here is a sample of what to expect in the log file or the event log:
-----------------12/20/2002 3:00:36 PM-----------------
SessionID:qwyvaojenw1ad1553ftnesmq
Form Data:
__VIEWSTATE - dDwtNTMwNzcxMzI0Ozs+4QI35VkUBmX1qfHHH8i25a/4g4A=
Button1 - Cause a generic error in the customer directory
1: Error Description:Exception of type System.Web.HttpUnhandledException was thrown.
1: Source:System.Web
1: Stack Trace: at System.Web.UI.Page.HandleError(Exception e)
1: at System.Web.UI.Page.ProcessRequestMain()
1: at System.Web.UI.Page.ProcessRequest()
1: at System.Web.UI.Page.ProcessRequest(HttpContext context)
1: at System.Web.CallHandlerExecutionStep.Execute()
1: at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
1: Target Site:Boolean HandleError(System.Exception)
2: Error Description:Object reference not set to an instance of an object.
2: Source:ErrorHandling
2: Stack Trace: at ErrorHandling.WebForm2.Button1_Click(Object sender, EventArgs e) in C:\Inetpub\wwwroot\ErrorHandling\Customers\WebForm2.aspx.vb:line 26
2: at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
2: at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
2: at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
2: at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
2: at System.Web.UI.Page.ProcessRequestMain()
2: Target Site:Void Button1_Click(System.Object, System.EventArgs)
First, the date and time is logged. Secondly, the user's session id is logged. These session ids look quite different than classic asp session ids which were all numeric. The next line contains any form data on the page. This is great especially if they filled in information on the page, and that information caused your app to bomb. All of the lines with "1" in front of it are the first error. This contains the description, source, stack track and what function caused the error. Starting at the "2"s, this is the error generated before #1. Error #2 here is the "InnerException" to error one. This is a new idea here (from classic asp or vb) since it allows error information to have a hierarchy to it. Some errors can be trapped, and rethrown with a new error giving more specific information.
Another idea is to use the SMTP component to e-mail you when an error occurs, enabling you to be proactive for errors. This would be a simple addition to the appSettings section above to hold an e-mail address and simply use the CErrorLog.GetErrorAsString to get the text needed to send an e-mail out.
Special Notes
- I read somewhere on the Net that someone recommended taking the error number and then looking up the proper message in a database to display to the user.
I like this idea; however, the downside is if an unexpected database error occurs, then you have just lost your errorpage ability.
- A quick note about performing a redirection inside a try-catch block:
If you want to redirect to a page within a given try-catch block in your code (custom error handlers included), understand this can fail under certain circumstances because a Response.Redirect calls Response.End within its internal code, creating problems. You must call Response.Redirect("pagename.aspx",False") which specifies the redirect call and will not call Response.End, thus, preventing the exception.
Good luck and happy error logging!

http://15seconds.com/issue/030102.htm

asp.net security tools

Microsoft güvenlik alanında ki vizyonunu değiştirdikten sonra, geliştiricilerin güvenli kod yazmasına ciddi şekilde yarar sağlayan bir çok araç çıkardı. Özellikle ASP.NET ve Visual Studio .NET için dağıttığı araçlar bir çok web uygulamasının güvenli ve belli bir kalitede çalışmasına önayak oldu. Teşekkürler derim.

Bir çok uygulamada benimde kendi açıklarımı kapatmamı sağlayan bu uygulamaları hatırlatmak istedim/isterim. (Gerçi bu bahane. Arayınca kolay bulmak için yazıyorum ^_^)

Microsoft Source Code Analyzer for SQL Injection
ASP scriptlerinizde Sql Injection sömürüsüne olanak veren kod olup olmadığını kontrol eden güzel bir uygulama.

Microsoft Anti-Cross Site Scripting Library V1.5
Cross-Site Scripting (XSS) 'e karşı daha güvenli kod yazmanıza olanak tanıyan .NET Sınıf kütüphanesi.

Microsoft Threat Analysis & Modeling v2.1.2 (İzlemelik)
Uygulamalarınızda güvenli olmayan Threat leri ve risk taşıyan metodları analiz edip ürününüzü daha güvenli tasarlamanıza yarayan bir araç.

XSS Detect Beta Code Analysis Tool
ASP.NET web projenize debug anında entegre olup XSS sömürüsüne olanak veren kod parçalarını gösterir ve düzeltmeniz için uyarır. Başarılı bir çalışma VS.NET 2005 için bir eklendi ama VS.NET 2008'de çalışması için Microsoft.ACE.XSSDetect.AddIn dosyasını açıp version node'unu 9.0 yapmanız gerekir.


http://www.oguzhan.info/bak.asp?458/ASP.NET+i%E7in+g%FCvenlik+ara%E7lar%FD.

Web Uygulamalarında Tehdit Modelleme ve Güvenlik

Tehdit Modelleme
.NET ve ASP.NET tarafından sağlanan güvenlik çatısı güçlü olsa da bazı temel prensipleri akılda tutmak ve bu özellikleri doğru bir şekilde ve doğru zamanda kullanmak gereklidir. Bunun için güvenlik öğelerini, uygulama geliştirmenin ilk aşamasından itibaren kullanmak gereklidir.

Güvenli (secure) mimariler dizayn etmek için uygulama ortamının çok iyi bilinmesi gerekir. Mesela uygulamamıza kimler erişecek ve muhtemel kötü niyetli ataklar nereden gelebilir vb. Dolayısıyla güvenli uygulama mimarileri ve dizaynları geliştirmede en önemli faktör, çevresel öğeleri çok iyi anlamaktır. Bunlar kullanıcılar, uygulamadaki giriş noktaları ve muhtemel atak noktalarıdır.
Bu yüzden Tehdit modelleme, günümüz yazılım mimarisinde önemli bir yer teşkil etmektedir. Tehdit modelleme (Threat modelling) muhtemel tehditler, bu tehditleri önem sırasına koyma ve sonra bu tehditleri temel alanhafifletme tekniklerine (mitigation techniques) karar verme üzerine uygulamamızın öğelerini analiz etmenin yapısal bir yoludur. Tehdit modelleme başka bir yönden de önem arz etmektedir. Bildiğimiz gibi bütün potansiyel tehditler, authentication ve authorization gibi güvenlik teknolojileri ile hafifletilemiyor. Bir başka deyişle bazı tehditler teknik yollarla çözüme kavuşturulamıyor. Mesela bir bankanın online şubesi, web sitesi üzerindeki trafiği güvenlik altına almak için SSL kullanıyor (Secure Socket Layer). Fakat kullanıcı, sayfanın bankanın gerçek sayfası olduğunu, bir hacker"ın sahte sitesi olmadığını nasıl anlayacak? Bunun tek bir yolu var: SSL kanalını kurmak için kullanılan sertifikaya bakmak. Ancak her kullanıcının bunun farkında olması düşük bir ihtimaldir; dolayısıyla kullanıcıları bilgilendirmeliyiz. Bu senaryodakine benzer hafifletme teknikleri, birer güvenlik teknolojisi değillerdir. Bu, bütün kayıtlı (registered) kullanıcıların sertifikaya nasıl bakmaları gerektiğini bildiklerinden emin olmayı gerektirir (Tabi ki onları bunun için zorlayamayız; fakat bilgileri doğru şekilde dizayn edersek bir çoğuna bunu yaptırabiliriz). Tehdit modelleme, sadece teknik konuları değil bu gibi durumları belirlemeye yardım eden bir analiz metodudur.
Güvenli kod yazmanın temel prensipleri

Kullanıcıların kontroller vasıtasıyla yaptıkları girişlere asla güvenilmemelidir... Tersi ispatlanana kadar bütün kullanıcılar birer şeytandır prensibini de unutmamak gerekir. Dolayısıyla girişler, çok kuvvetli bir şekilde doğrulanmalıdır (validation). En doğru olan, sadece girilmesi gereken değerlere izin vermektir.
SQL ifadeleri yazarken asla string birleştirme kullanılmamalıdır... Sql"den iğne yemek istemiyorsanız (sql injection) her zaman parametrelendirilmiş sorgular kullanılmalısınız. Aynı zamanda sql cümlelerin olduğu yerlerde try-catch bloğu sonucu kullanıcıya verilecek hata mesajında kendi özel mesajımızı kullanmak daha güvenlidir; çünkü Exception ya da Exception türevi sınıfların Message özelliği ile kullanıcıya veritabanımız hakkında bilgi gösterilebilir.
Kullanıcıdan alınan bilgiler, doğrulanmadan ve encode edilmeden; yani doğrudan web sayfasında gösterilmemelidir... Kullanıcı bazı HTML parçaları girebilir (mesela bir script). Bu yüzden her zaman HttpUtility.HtmlEncode() kullanarak < ve > gibi karakterlerden kaçmakda fayda vardır. Alternatif olarak bu geçerlilik kontrolünü yapacak bir web kontrolü kullanılabilir.
Sayfanın gizli alanlarında (hidden field) önemli, değerli, iş bilgisi taşıyan ya da akışı etkileyecek veri saklamamak gerekir. (Gizli alanlar tarayıcıdaki kaynak sayfaya bakılarak kolayca görülebilir, değiştirilebilir, kaydedilebilirler. Ardından da tarayıcı eklentileri (browser plug-in) ile mail gönderir gibi sunucuya gönderilebilirler)
View-state içerisinde önemli, kritik veri saklanmamalıdır (Çünkü view-state, bir gizli alandır. Kolayca decode edilebilir. Bu arada eğer sayfada @Page etiketinde EnableViewStateMac = true yapılırsa view-state şifrelenir).
Cookie"ler korunmalıdır... Forms authentication kullanılırken cookie"ler olabildiğince geç oluşturulup ihtiyaç kalmadığında silinmesi için timeout süresine sahip olmalıdır.
SSL kullanılmalıdır... Eğer web sitemiz, genel olarak hassas veriler içeriyorsa bütün siteyi SSL kullanarak koruma altına almak gerekir. Ayrıca direk SSL tarafından korunamayan resim ve diğer dosyaları da korumayı unutmamak lazım.

ASP.NET GateKeeper"ları ve Sorumlulukları

Uygulamamızın güvenliğini artırmanın güzel bir yolu, yerinde birçok bileşenle güvenliği sağlamaktır. Gatekeepers (takipçiler, koruyucular), güvenlik altyapısına bir yol bir boru hattı modeli yerleştiren kavramsal bir oluşumdur. Bu model, güvenliği artırmamıza yardımcı olur. Gatekeeper modeli şunu savunur ki; uygulamaya gerektiğinden fazla güvenlik mekanizmaları koymak gerekir. Bu mekanizmalardan her birine güvenlikle ilişkili bazı koşullara zorlamaktan sorumlu gatekeeper adı verilir.Eğer gatekeeperlardan biri başarısız olursa, hacker kaynaklara giden yoldaki diğer gatekeeper"la karşılaşacaktır. Ne kadar çok gatekeeper varsa, hacker"ın hayatı o kadar zorlaşır. Bu model, güvenli uygulamalar geliştirmek için zorunlu prensipleri desteklemektedir: Olabildiğince güvenli ol, hacker"ların hayatını olabildiğince zorlaştır. Yolun sonunda kaynaklara ulaşmak için gereken gatekeeperlar aşıldığında belki sadece sayfamızın kodları vardır, ancak yine de bu güvenlik prensipleri uygulanmalıdır. Bu şekilde merkezi bir güvenlik bileşeni uygulamak iyi bir fikir olabilir. Aynı şeklide iş katmanı da güvenli hale getirilebilir. ASP.NET uygulama altyapısı, bunu güzel bir şekilde uygulamaktadır.
Bir web sitesinde güvenliği uygulamanın yolları genelde aynıdır (Ayrıca tehdit modellemede bizim belirleyeceğimiz seviyeler bunlara eklenebilir).
Authentication : Öncelikle kullanıcıların kimliklerini doğrulamak gereklidir. Authentication şu soruyu sorar: Uygulamayı kullanan kim?
Authorization : Uygulamamızla çalışanın kim olduğunu öğrendikten sonra o kullanıcının hangi operasyonları gerçekleştirebileceğini ve hangi kaynaklara erişebileceğine karar vermek gereklidir. Yani authorization şu soruyu sorar; Senin geçiş iznin ne?

Güvenilirlik : Kullanıcı uygulama üzerinde çalışırken kimsenin kullanıcı tarafından işlenen hassas verileri görmediğinden emin olmak gerekir. Bu yüzden kullanıcı tarayıcısı ile web sunucumuz arasındaki kanalı şifrelemek gerekir (SSL). Dahası, arka plandaki verileri de şifrelemek gerekir. Mesela kullanıcı makinesine atılan cookieleri... Aynı zamanda veritabanı yöneticisi ve uygulamanın yayınlandığı (host edildiği) şirketin çalışanlarının da görmemesi için verileri şifrelemek gereklidir.
Tutarlılık : Tarayıcı ve sunucu arasında gidip gelen verinin illegal aktörler tarafından değiştirilmediğinden emin olmak gerekir. Bu tarz tehditleri hafifletmenin bir yolu dijital imza kullanmaktır.

ASP.NET, authentication ve authorization için bize basit bir altyapı sunar. Ayrıca .NET Framework ile gelen temel sınıf kütüphanesinde, System.Security isim alanı altında veriyi şifreleme ve imzalama için bazı sınıflar bulunmaktadır.

Authentiction

ASP.NET"de 4 tür kimlik doğrulama sistemi mevcuttur. Bunlar :

1) Windows authentication
2) Forms authentication
3) Passport authentication
4) Custom authentication
Mesela windows işletim sistemi, login olan her kullanici için 96-bit bir numara kullanır, buna SID (Security identifier) denir. Bütün authentication çeşitleri, sunucuya talepte bulunan kişinin kim olduğunu bilmemizi sağlar ki bundan kişiselleştirme için faydalanılabilir. Çünkü kimlik (identity) bilgisini web sayfasında kişiye özel karşılama mesajı göstermek için veya sayfanın görünüşünü değiştirmek için kullanabiliriz. Yine de kullanıcının uygulama içerisinde yapacaklarını kısıtlamak için authentication yeterli değildir. Bunun için authorization gereklidir.
Güvenilirlik ve Uyumluluk için Şifreleme
Güvenilirlik (Confidentiality), verinin ağ (network) üzerinde sunucu ve istemci tarayıcısı arasında gidip gelirken ya da bir veri kaynağına kaydedilirken başka kullanıcılar tarafından görülmemesidir.
Uyumluluk (Integrity) ise, yine ağ (network) üzerindeki ya da veri kaynağına kaydedilen verinin başka kullanıcılar tarafından değiştirilmediğinden emin olunmasıdır. Her ikisi de şifreleme (encryption) tabanlıdır. Şifreleme, veriyi karıştırmak, dolayısıyla bir kullanıcı tarafından okunmasını engellemek demektir. ASP.NET"de şifreleme, authentiction ve authorization"dan tamamen farklı bir özelliktir. Şifrelemeyi tek başına da, diğer özelliklerle bir arada da kullanabiliriz. Bir web uygulamasında şirelemeyi iki sebebten dolayı kullanmak isteyebiliriz:
1. Ağ üzerindeki verinin iletişimini korumak için: Mesela internet ortamında bir e-ticaret sitesinden alış-veriş yaparken bu ortamda bulunabilecek bir dinleyicinin (eavesdropper) kredi kartı no"mu okuyamadığından emin olmak isteyebilirim. Endüstriyel standartların yaklaşımına göre bunun çözümü SSL (Secure socket layer)"dir. SSL aynı zamanda tutarlılığı sağlamak adına dijital imza da sağlamaktadır. SSL, ASP.NET tarafından sağlanmaz, bu IIS"e entegre edilebilecek bir özellikir.
2. Veritabanı ya da bir dosyadaki kalıcı bilgileri korumak için:  Mesela gelecekte kulanmak üzere  kullanıcının kredi kartı no"sunu veritabanına kaydetmek istiyoruz. Bunu açık metin (plain text) olarak kaydedebilmemize rağmen, çok da iyi bir fikir değildir. Bunun yerine veritabanına kaydetmeden önce .NET framework tarafından bize sağlanan tipler yardımıyla veri şifrelenebilir.
Şu ana kadar anlatılanları bir araya getirirsek :
Kullanıcı bir siteye girdiğinde isimsiz bir kullanıcıdır (anonymous user). Yani uygulamamız gelenin kim olduğunu bilmez ve bu onu ilgilendirmez. Onu doğrulamadığımız (authenticate etmediğimiz) sürece de öyle kalacaktır. Varsayılan olarak isimsiz kullanıcılar bütün ASP.NET web sayfalarına erişebilirler. Fakat isimsiz erişimi olmayan bir siteye girildiği zaman şu aşamalar gerçekleşir:
1) Talep web sunucusuna gönderilir. Bu aşamada kullanıcının kimliği (identity) bilinmediği için ona login olması söylenir. (Bunun için özel bir web sayfası hazırlanabilir) Login sürecindeki ayrıntılar, authentication türüne bağlı olarak değişir.
2) Kullanıcı güvenlik bilgilerini verir ve ardından eğer form authentication kullanılıyorsa uygulamamız tarafından, windows authentication kullanılıyorsa IIS tarafından kontrol edilir.
3) Eğer bilgiler doğruysa kullanıcı talep ettiği sayfaya yönlendirilir. Verilen bilgiler doğru değilse kullanıcı yeniden log-in sayfasına yada Erişim reddedildi mesajı içeren bir web sayfasına yönlendirilir.
Kullanıcı sadece belli kullanıcılara ya da belli role sahip kullanıcılara açık bir web sayfası talep ederse yukarıda anlatılan aynı süreçten geçer fakat bu sefer fazladan bir adım vardır. Kullanıcı eğer bilgilerini doğru girmişse, talep ettiği sayfaya giriş hakkı olup olmadığı da kontrol edilir. Bu da sürecin authorization kısmıdır. Eğer kullanıcının talep ettiği kaynağa hakkı yoksa Erişim reddedildi mesajı içeren bir web sayfasına yönlendirilir.


http://www.bilgininadresi.net/Madde/791/Web-Uygulamalarında-Tehdit-Modelleme-ve-Güvenlik