Sending the user somewhere else in C#

Encode Code 3 of 9 in C# Sending the user somewhere else

One of the most common uses of the Response object is to send the user somewhere else entirely If you look at the request headers and realize (for instance) that the user isn t logged into a Windows domain account (using HttpRequestIsAuthenticated), you can redirect the user to a login screen:

If(!RequestIsAuthenticated){ ResponseRedirect( loginaspx ); }

On the other hand, sometimes you need to tell the user that this isn t the right place to be at all Especially useful if you have to change the structure of your Web site, RedirectPermanently tells search engine spiders nope, this isn t here anymore Go over there and change your index For instance, say you have a product line that was moved to a whole new URL You could check the QueryString for the product line statement, and if you find it, redirect the link permanently

If(RequestQuerystring( ProductLineId )==4){ ResponseRedirectPermanently( http://newproductcom ) }

Sometimes you just want to change things directly ResponseWrite, ResponseWriteFile, and Response WriteSubstitution all are designed to allow you to do just that In the old days (before debugging), we had to use ResponseWrite to put errors into the HTML that we could view with ViewSource If you are using MVC, there is still a place for that In today s development, ResponseWrite is mostly used to do something that you want to do on every page that meets a certain criteria, no matter who coded it You can add it to the code-behind of the master page (more on that in 5) and know that the output stream of the site will be altered directly

Book III covers security, and there is a whole book on security that you should read Code Complete by Steve McConnell I m only covering security in this chapter because the AspNetHostingPermission is in the SystemWeb namespace, and I want to give it a little airtime ASPNET security is a complex topic Because visitors to a Web site are anonymous, bypassing the Windows security system occurs often That bypassing called impersonation allows IIS to do things on behalf of the user even if the user isn t really known to Windows Remember, just because you have put in a username and password doesn t mean that Windows is okay with your credentials

So ASPNET Web sites are run most often with whatever permissions the IIS service is running with Under normal conditions, this service is a fairly restricted account called Network Service The fact is, however, that you really have no idea what the permissions will be because a hosting company most likely will be managing that Your users can have administrative permissions for all you know You can purposefully restrict the permissions of your users in your code This prevents someone from finding a way through your code logic to call a method you don t want them to be able to call Believe me, it happens The general idea is to trust no one, which I harp on in the Security chapter in Book III You want to pretend that most people who are going to run your code are the enemy I realize that isn t any fun But it is necessary today There are pre-built scripts to break into Web pages there doesn t even have to be a real person there to bust in The MSDN documentation states this: It is recommended that you set the level attribute of the trust configuration element to High for sites that are trusted For sites that are not trusted, such as a Web server that hosts sites that run code from an external customer, it is recommended that you set the level attribute of the trust configuration element to Medium For the record, sites without a permission level set default to Full, which is obviously higher than either of those