c# asp代写: tic-Tac-Toe Authentication

1. [45 points] Tic-Tac-Toe Authentication
Login The objectives of this homework assignment are as follows:
• To write and successfully build a functional ASP.NET Web Application.
• To learn how to use Web Forms and handle server control events.
• To build a mechanism called a user session, which you will use to track user sessions (rather than
browser sessions).

  • To learn how to read and write browser cookies.
  • To gain a basic understanding of how sensitive information is hashed1 .
  • To use ASP.NET server controls to manage Tic-Tac-Toe gameplay and screen appearance.
  • To code a simple game in C#.
    In this exercise, you will create an ASP.NET web application which will contain three pages:
    • a login form called Default.aspx
    • a public form called Public.aspx containing information available to the world
    • a restricted form called TicTacToe.aspx, containing a Tic-Tac-Toe game that is restricted to authenticated
    users.
    For the avoidance of doubt, a a working implementation of the homework assignment is available for
    viewing. The functional requirements are as follows:
    1. All users will be able to access all three pages described above at any time. However, the restricted
    page, TicTacToe.aspx, will contain a live version of the Tic-Tac-Toe game, using the HTML and styling we discussed in class. The site will show this page only if the user is authenticated; otherwise
    it should display a message advising the user to authenticate first and provide a link to Default.aspx
    for that purpose.
    2. The login screen, Default.aspx, will prompt the user for a username and password. Credentials
    should be stored in the server memory, whereby the password should be hashed using the Crypto
    class.
    (a) If the username has never been previously authenticated, the login screen will behave as a registration screen. The login credentials entered by the user will be stored in server memory and a successful registration should also be treated as a successful authentication.
    (b) If the username has been successfully authenticated at some point in the past, the credentials
    entered on the login screen should be validated against the credentials in server memory. If not valid, the user should be informed of the invalid login and be given unlimited opportunities to enter the correct credentials without leaving the login page.
    3. Immediately upon successful authentication, several things should happen:

• Create a user session by generating a unique user session ID. This will be stored in server memory
and in a browser cookie (see below) and this cookie will be sent to the server upon each page request to identify the specific user that is logged into the system. A global unique identifier

(GUID) can be used for creating a unique ID. You may call Guid.NewGuid().ToString()
to generate a GUID in string form, or you can roll your own. You may also use the built-in Session State to do this if you wish.
1Hashing refers to a one-way encryption scheme in which a plain-text string can be converted to an encrypted string, but
not vice versa. The most common hash algorithms are MD5, SHA-1, SHA-256, SHA-512. We will be using PKCS #5.
Page 2
• The login credentials should be stored in server memory. The credentials should include at least
the username, hashed password, plain text session ID, and session expiration, which should be set to 10 minutes in the future. After 10 minutes, the user session should no longer be recognized
and the user must authenticate again in order to play the Tic-Tac-Toe game at TicTacToe.aspx. The expiration should only be set at login—it should not be refreshed anytime during the user’s session. The session expiration should not be implemented as a cookie expiration.
The password can be hashed using the Crypto class. You should use Crypto.HashPassword to convert a plain text string into a hashed string. Use Crypto.VerifyHashedPassword to verify
a previously hashed string against a plain text string. Although the method names suggest
that the hashing is for passwords only, you can hash any string you want with this method (including the session ID).
• The user should be redirected to TicTacToe.aspx. This can be accomplished using method Response.Redirect.
• Any subsequent views of Default.aspx during the 10 minute period that the user is logged in should present the user with only a “Log Off” button. Pressing that button should cause the
user session to end and the username/password fields to become visible again.
4. Upon unsuccessful authentication, no special action is necessary—the user should be able to try
again an unlimited amount of times. Best practices call for the limitation of login attempts to reduce the chance of successful password guessing. This is normally handled by forcing the user to
wait a period of time before trying again, or locking out the account. Again, you need not limit the number of logins for this assignment.
5. You may construct Default.aspx any way you wish, but the Login server control from the toolbox
is recommended since it contains the fields for entering the username and password. If you
use this server control, you are responsible for implementing the login logic. This logic should be performed in the event handler Login_Authenticate, where Login is assumed to be the ID

of the Login server control (you can name it anything you want). Inside this handler, assign e.Authenticated to either true or false to reflect the outcome of the authentication. Doing
so will inform the Login control whether or not to display an error message. The “auto event wireup” feature makes it possible to handle this event simply by adding it to the code-behind file without needing to subscribe to the event explicitly. The proper signature for the event handler is:

protected void Login_Authenticate(object sender, AuthenticateEventArgs e).
6. As indicated above, user credentials should be stored in server memory. It is recommended that
you create a separate C# code file containing single class with all of the necessary properties. You
may then store instances of these objects in server memory. You can use Application State to store
objects if you wish. Because Application State might be accessed simultaneously by numerous request threads, you should surround any read or write operations involving Application State with
calls to Application.Lock() and Application.Unlock() to prevent race conditions. Although
this is acceptable for the current assignment, this approach is not scalable and should not be implemented in practice.
To add a C# code file to the project, right-click on the project, go to Add and then New Item…, select Code on the left side and then Class. Feel free to create additional classes if you wish—the
convention is to store each one in its own code file.
7. The password and user session ID should be salted. Salt is nothing more than adding a sequence
of random characters to the plain text string you want to hash. Its main purpose is to reduce the chance of the user “cracking” the hash algorithm, particularly using shorter passwords. Fortunately,
salting is done for you by the Crypto library as long as you use the Crypto.HashPassword and Crypto.VerifyHashedPassword methods.
To set up the project, please perform the following actions:
1. Create a new ASP.NET Web Application. When the New ASP.NET Project dialog appears, select
the “ASP.NET Web Forms Site” template. For this exercise, it is not necessary to check the boxes
for adding the project to source control.
Page 3
2. Use the NuGet package manager to obtain the microsoft-web-helpers package, which contains
the Crypto class.
3. In any code-behind file in which you use the Crypto routines, you will first need to add the directive,
using System.Web.Helpers;.

4. Go to the Web.config file, and add the following directly beneath the opening configuration tag:
<appSettings>
<add key=”ValidationSettings:UnobtrusiveValidationMode” value=”None” />

</appSettings>
This will be necessary to use the Login server control without errors.
5. Once the solution is created, it will contain a single project with no web forms. To create a new
web form, right-click on the project (not the solution) in Visual Studio, choose Add, New Item…, and then select Web Form from the dialog.
6. The web form Public.aspx should represent the publicly accessible page that anybody can view.
There is no specific requirement for the appearance of this page, other than it must contain something
of substance (i.e., not be empty or nearly empty) and be well-styled.
7. Add a new web form, TicTacToe.aspx, which will display the Tic-Tac-Toe game board if the user
is authenticated. You will need to move the HTML and CSS from the previous in-class demo into this page. The requirements of the game itself are discussed later in this assignment. As discussed previously, the page must confirm that the user is authenticated by verifying the hashed
user session ID against the user session ID in server memory for the user in question. If the user
is not authenticated, the page must indicate to the user that they must login before viewing the resume. A link to Default.aspx should be provided for this purpose.
Page 4
2. [10 points] Security
After implementing the solution above, please answer the following questions:
1. In the assignment above, we store the store the user session ID in encrypted form in the browser
cookie. Explain one type of security breach scenario that could occur if it were instead stored in plain text?
2. What happens if a user tampers with the encrypted user session ID value in the cookie? You can
either answer based on your knowledge of sessions (as described above), or try it out by modifying
the value of the cookie after it has been stored on the browser (if you know how to do this in your
particular browser).
3. In the assignment above, we store the username in plain text in the browser cookie. If the user
tampers with this value, the system should still not permit unauthorized access. Explain why.
4. When HTTP packets are sent across an encrypted channel (HTTPS), the entire HTTP

packet,
including the header and the contents are all encrypted. We did not consider this requirement
in the assignment above, but you should always be thinking about this. Of the three pages you implemented, which of these pages should you insist be sent only over a secure connection, and
why?
5. This homework requires only the password to be encrypted in server memory. However, in practice,
the user session ID should ideally be encrypted also. Why?
6. Above, we require that the session expiration not be implemented as a cookie expiration. Why?
Page 5
3. [45 points] Tic-Tac-Toe Game
Earlier in the class, we styled a Tic-Tac-Toe board for a static HTML document. Now you get to make
the board come to life by programming the logic to turn it into a fully functional Tic-Tac-Toe game.
The requirements are as follows:
1. The board is initially empty when the game begins.
2. Players will alternate taking turns: first X will go, then O, then X, and so on.
3. When either player attains 3 of their own mark down, across, or diagonally, they win.
4. If the board becomes full and nobody has won (according to above), the game is tied.
5. The screen will indicate whether the current turn is for player X or O. It will also indicate that X has won, O has won, or that the game is tied.
6. As long as the game is active, each empty box on the board can be clicked to place a mark in the
box that corresponds to the current player. Clicking on a box causes the change of players so that
the next mark will be the other player’s.
7. Any box that has an X or O mark in it can never be clicked (i.e., the board will not be updated in
any way).
8. At any time, the user can click the “Tic Tac Toe” item on the navigation bar to start a new game
(provided the user is authenticated).
9. If a user starts a game, logs out, then logs back in, it is not necessary to save the previous state of
the game. However, feel free to add this feature if you wish.
Here are some hints for implementing the game:
• The best way to get started with the Tic-Tac-Toe game is to transfer the HTML and CSS from the in-class demo (See NYU Classes) over to the ASP.NET Web Forms Application. The HTML will go into the TicTacToe.aspx file, then edit as necessary. The CSS should go into a “Styles” directory that you create.

• Consider using a master page to put the html, head and body tags. This is also a good place to put
the navigation bar. Use a ContentPlaceHolder and put each of your pages in their own .ASPX file.

• Consider using Button and Image controls inside each of the 9 div boxes of the Tic-Tac-Toe board.
Use the Button to place a mark in the box and use each Button’s OnClick event handler to respond

to box clicks and perform the game logic. Use the Image to display a mark. Programmatically show and hide these as necessary.
• The entire game can be handled on a single .ASPX page using postbacks.
• Remember you can turn any HTML element into a server control and programmatically manipulate

it. This might be handy for hiding the Tic-Tac-Toe board when the user is not authenticated, among
other things. When you turn HTML elements into server controls, you may notice some of your CSS styling goes away. This is because .NET creates its own id for each server control, and HTML

tags you may have styled will no longer work. Use developer tools to see the newly assigned names
and change your styling accordingly to reflect this.
• Consider using ScriptManager, UpdatePanel and ContentTemplate to enable AJAX and eliminate

screen flickering whenever a player makes a move. Using these controls may result in new div tags
(and possibly others) being added around your game board, which may also mess with your existing

CSS styling. Use developer tools to watch for them and be prepared to do some additional CSS styling to address the issues.