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

项目预算：开发周期：发布时间：要求地区：

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