Merge pull request #3855 from aspnet/master

Update live with current master

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)
 

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.
 
 

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
 

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.