program代做、代写Java/c++设计编程

日期：2024-02-25 08:26

Step #2: Create a self-signed certificate. HTTPS connections require TLS, and, in order to use TLS, your

server will need a certificate. For testing, you may want to create a self-signed certificate. You can do this

using the keytool utility, with is included in the JDK. An example command would be (on a single line):

keytool -genkeypair -keyalg RSA -alias selfsigned -keystore keystore.jks

-storepass secret -dname "CN=Blah, OU=Blubb, O=Foo, L=Bar, C=US"

This will create a file called keystore.jks in the local directory.

Step #3: Open a TLS socket. As a first step, implement the securePort method, and then add code to

replace the existing server socket with a TLS server socket. You can use code roughly like the following:

import javax.net.ssl.*;

import java.security.*;

String pwd = "secret";

KeyStore keyStore = KeyStore.getInstance("JKS");

keyStore.load(new FileInputStream("keystore.jks"), pwd.toCharArray());

KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");

keyManagerFactory.init(keyStore, pwd.toCharArray());

SSLContext sslContext = SSLContext.getInstance("TLS");

sslContext.init(keyManagerFactory.getKeyManagers(), null, null);

ServerSocketFactory factory = sslContext.getServerSocketFactory();

ServerSocket serverSocketTLS = factory.createServerSocket(securePortNo);

You should now be able to use serverSocketTLS instead of your existing server socket. (This will

disable normal HTTP requests for now, but we’ll fix this shortly.) Try running a simple test application on

your server, like

securePort(8443);

get("/", (req,res) -> { return "Hello World!"; });

and then open https://localhost:8443/ in your web browser. (Be sure to include the https

part!) If you are using the self-signed certificate from Step #2, which is not signed by any CA, you will see

lots of warnings in the browser, but it should be possible to override them. For instance, in Safari you would

see a warning that says that “This Connection Is Not Private”, but you can click on “Details”, then on “visit

this website”, and then confirm by clicking on the “Visit Website” button. At the end, you should see the

“Hello World!” message from the test application, and you should be able to view the information in your

self-signed certificate by clicking on the little lock icon in Safari’s address bar (or whatever equivalent your

favorite browser has to this). If the lock icon is missing or you do not get any warnings, something is

wrong; chances are that you are still using HTTP. Also, at this point, the https test case should pass.

Step #4: Add back HTTP support. In order to support both HTTP and HTTPS, which use different ports,

your server will need to listen to two different server sockets. A simple way to do that is to use two

separate threads. If you haven’t already, you should factor out your server loop into a separate method, say

serverLoop(s), where s is a ServerSocket; at that point, you can simply open both a normal

server socket and a TLS server socket, and then launch two separate threads that each invoke this method

with one of the two server sockets. At this point, both the http and https test cases should pass.

Step #5: Add a session object. Next, create a class – perhaps called SessionImpl – that implements

the Session interface. This class doesn’t have to do much; all it needs to do is store the various bits of

information (the session ID, creation time and last-accessed time, max active interval, and key-value pairs)

and implement the various getter and setter methods in the interface.

Step #6: Add session handling. Now you can use this class to add support for sessions. There are four

places in the server that need changes. First, you need a data structure that stores the sessions by session ID

– probably some kind of Map. Second, you’ll need to parse the Cookie header(s) while reading the

3

request, and extract the cookie with the name SessionID, if it exists; if it does, and your Map contains a

session for that ID, update that session’s last-accessed time and make sure that the session() method

will return it when called. Third, when session() is called and there is not already a session, you’ll

need to create a new object with a fresh session ID. Keep in mind that the session ID should be random and

have at least 120 bits; for instance, you can pick a set of 64 characters (maybe lower and upper case letters,

digits, and two other characters) and then draw 20 of them. Finally, when writing out the headers, you’ll

need to add a Set-Cookie header whenever you’ve created a new SessionImpl object, to send back

the corresponding SessionID cookie to the user. With this, you should be able to implement the two

attribute methods from the Session interface, and both the sessionid and permanent test

cases should pass.

Step #7: Add session expiration. The final step is to add a way to expire session objects. This requires

two steps. First, you’ll need a way to periodically expire old sessions that have not been accessed recently;

you can do this by launching another thread that sleeps for a few seconds, removes any session objects

whose last-accessed timestamp is too old, and then repeats. Notice, however, that this could cause the

server to slightly overshoot the lifetime of a session. To fix that, the second step is to also check the

last-accessed timestamp before updating it, and to simply ignore the object if it has already expired but has

not been deleted yet. At this point, both the expire test case should pass.

Step #8: Implement a test server. Write a little server that 1) calls securePort(443) to set the

HTTPS port, and 2) defines a GET route for / that returns the required message from Section 2. Test this

server locally (https://localhost/) with your self-signed certificate, to make sure that it displays

the message correctly. If you cannot bind to port 443 on your local machine, you can use port 8443 for

testing (in this case, open https://localhost:8443/ instead), but please don’t forget to use 443 in

the final version that will be deployed on EC2.

Step #9: Launch an EC2 instance. Log into the Amazon Web Services console and choose EC2 (by

clicking on “Services”, then on “Compute”, and then on “EC2”). Click on “Launch Instance”, and then do

the following:

? Under “Application and OS Images”, choose the default Amazon Linux AMI (Amazon Linux 2023).

? Under “Instance type”, choose one of the smallest/cheapest instances – say, a t2.micro instance.

This should be enough for our purposes.

? Under “Key Pair”, click on “Create new key pair”, choose a descriptive name (perhaps “CIS5550”),

and pick RSA and the .pem format. Hit “Create Key Pair”, which should cause your browser to

download a .pem file.

? Under “Network settings”, make sure that the following three options are checked: “Allow SSH

traffic from Anywhere”, “Allow HTTPS traffic from the internet”, and “Allow HTTP traffic from the

internet”. Please double-check this – if you get this step wrong, chances are that you won’t be able to

connect to your server later on.

? Under “Configure storage”, you can keep the default, which is probably an 8GB gp3 root volume.

In the summary bar on the right, double-check that the number of instances is 1, and then hit the orange

“Launch instance” button. Wait a moment, until (hopefully) AWS reports success. Go back to the

“Instances” tab in EC2, and find the instance you just launched. When you click on its instance ID, you

should see an “Instance summary” that shows, among lots of other things, its public IPv4 address. Write

this down. (Do not confuse this with the private IPv4 address, which probably starts with 172. or 10.

and won’t be useful for our purposes!)

4