diff --git a/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages.md b/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages.md index 7266825ff6..aabf8cc0ec 100644 --- a/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages.md +++ b/aspnet/web-api/overview/getting-started-with-aspnet-web-api/creating-api-help-pages.md @@ -45,7 +45,7 @@ The main part of the page is a table of APIs, grouped by controller. The table e The "API" column lists the HTTP method and relative URI. The "Description" column contains documentation for each API. Initially, the documentation is just placeholder text. In the next section, I'll show you how to add documentation from XML comments. -Each API has a link to a page with mroe detailed information, including example request and response bodies. +Each API has a link to a page with more detailed information, including example request and response bodies. ![](creating-api-help-pages/_static/image5.png) diff --git a/aspnet/web-forms/overview/getting-started/creating-a-basic-web-forms-page.md b/aspnet/web-forms/overview/getting-started/creating-a-basic-web-forms-page.md index 3ee434345c..1f699c38dd 100644 --- a/aspnet/web-forms/overview/getting-started/creating-a-basic-web-forms-page.md +++ b/aspnet/web-forms/overview/getting-started/creating-a-basic-web-forms-page.md @@ -307,7 +307,7 @@ In this section, you will program the [Calendar](https://msdn.microsoft.com/libr 1. In **Design** view, double-click the [Calendar](https://msdn.microsoft.com/library/system.web.ui.webcontrols.calendar.aspx) control. - A new event handler is created and displayed in teh code-behind file named *FirstWebPage.aspx.cs*. + A new event handler is created and displayed in the code-behind file named *FirstWebPage.aspx.cs*. 2. Finish the [SelectionChanged](https://msdn.microsoft.com/library/system.web.ui.webcontrols.calendar.selectionchanged.aspx) event handler with the following code. diff --git a/aspnetcore/security/anti-request-forgery.md b/aspnetcore/security/anti-request-forgery.md index cbf607e1c9..81c5413052 100644 --- a/aspnetcore/security/anti-request-forgery.md +++ b/aspnetcore/security/anti-request-forgery.md @@ -340,7 +340,7 @@ The [IAntiForgeryAdditionalDataProvider](https://docs.microsoft.com/aspnet/core/ CSRF attacks rely on the default browser behavior of sending cookies associated with a domain with every request made to that domain. These cookies are stored within the browser. They frequently include session cookies for authenticated users. Cookie-based authentication is a popular form of authentication. Token-based authentication systems have been growing in popularity, especially for SPAs and other "smart client" scenarios. -### Cookie based authentication +### Cookie-based authentication Once a user has authenticated using their username and password, they are issued a token that can be used to identify them and validate that they have been authenticated. The token is stored as a cookie that accompanies every request the client makes. Generating and validating this cookie is done by the cookie authentication middleware. ASP.NET Core provides cookie [middleware](../fundamentals/middleware.md) which serializes a user principal into an encrypted cookie and then, on subsequent requests, validates the cookie, recreates the principal and assigns it to the `User` property on `HttpContext`. @@ -350,7 +350,7 @@ When a user is logged in to a system, a user session is created on the server-si ### User tokens -Token based authentication doesn’t store session on the server. Instead, when a user is logged in they are issued a token (not an antiforgery token). This token holds all the data that is required to validate the token. It also contains user information, in the form of [claims](https://msdn.microsoft.com/library/ff359101.aspx). When a user wants to access a server resource requiring authentication, the token is sent to the server with an additional authorization header in form of Bearer {token}. This makes the application stateless since in each subsequent request the token is passed in the request for server-side validation. This token is not *encrypted*; rather it is *encoded*. On the server-side the token can be decoded to access the raw information within the token. To send the token in subsequent requests, you can either store it in browser’s local storage or in a cookie. You don’t have to worry about XSRF vulnerability if your token is stored in the local storage, but it is an issue if the token is stored in a cookie. +Token-based authentication doesn’t store session on the server. Instead, when a user is logged in they are issued a token (not an antiforgery token). This token holds all the data that is required to validate the token. It also contains user information, in the form of [claims](https://msdn.microsoft.com/library/ff359101.aspx). When a user wants to access a server resource requiring authentication, the token is sent to the server with an additional authorization header in form of Bearer {token}. This makes the application stateless since in each subsequent request the token is passed in the request for server-side validation. This token is not *encrypted*; rather it is *encoded*. On the server-side the token can be decoded to access the raw information within the token. To send the token in subsequent requests, you can either store it in browser’s local storage or in a cookie. You don’t have to worry about XSRF vulnerability if your token is stored in the local storage, but it is an issue if the token is stored in a cookie. ### Multiple applications are hosted in one domain diff --git a/aspnetcore/security/cors.md b/aspnetcore/security/cors.md index 44ae7df314..d3f03d9ac4 100644 --- a/aspnetcore/security/cors.md +++ b/aspnetcore/security/cors.md @@ -216,7 +216,7 @@ The Access-Control-Max-Age header specifies how long the response to the preflig ## How CORS works -This section describes what happens in a CORS request, at the level of the HTTP messages. It’s important to understand how CORS works, so that you can configure the your CORS policy correctly, and troubleshoot if things don’t work as you expect. +This section describes what happens in a CORS request, at the level of the HTTP messages. It’s important to understand how CORS works, so that you can configure your CORS policy correctly, and troubleshoot if things don’t work as you expect. The CORS specification introduces several new HTTP headers that enable cross-origin requests. If a browser supports CORS, it sets these headers automatically for cross-origin requests; you don’t need to do anything special in your JavaScript code.