Aaron’s Status Report for 5/1

This week I worked on deploying the Django web app to AWS, as well as making some changes to the app to streamline transferring item information betweent the Javascript and Python portions of our app. After examining the various available AWS services, including Lightsail and Lambda, we decided to use AWS Elastic Beanstalk (EB) to host the web app. However, getting EB to work with our web app took a lot of experimenting as well as searching online for solutions to our problems.

The first problem I encountered was that EB did not have access to some of the Python packages which our Django app was using. In fact, EB actually does not support the most recent release of Python (3.9), so I had to set up a Python 3.8 environment to test run the web app on. I slowly determined which packages were problematic by looking at the EB environment initialization logs after each failed deployment. I downgraded or removed these packages until the EB environment succesfully deployed. One tip I wish I had known earlier is that the AWS command-line interface only deploys your most recent git commit, not just any changes that have been made to the local files. Thus, any changes have to be committed before the AWS CLI will upload them.

The second problem with our server was that the static files were not being served for the webpage. After reading various blogs about deploying Django apps on EB, I learned that the Nginx server running on the EB instance needs to be configured to serve the static files from a directory. Also, the Django app needs to be told to prepare the static files with the collectstatic command. Using the option-settings feature of EB, I created a configuration file which directed EB to run the necessary commands to prepare and serve the static files using Django and Nginx respectively.

We also learned that the Web Bluetooth API requires https in order to function, for security reasons. In order to make our site secure, I also had to create a self-signed development SSL certificate and upload it to the AWS Certificate Manager. My first few attempts failed due to the certificate being invalid, but after following this blog:

https://medium.com/@chamilad/adding-a-self-signed-ssl-certificate-to-aws-acm-88a123a04301

I managed to succesfully upload a certificate. I then added an HTTPS listener to our AWS EB instance using the certificate, and I also installed the certificate locally on my computer. However, the https still did not work, as modern browsers such as Chrome require that SSL certificates specify the Subject Alternative Name (SAN) field in order to be accepted. After following this Stack Exchange post:

https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line

I created a new certificate with the SAN field specified and the certificate was accepted.

After installing the certificate on my Android phone, I was also able to test and verify that our system works on a smartphone. Previously, we were unable to test this functionality because the Web Bluetooth API does not run unless https is enabled.

Schedule-wise, we are falling a bit behind on getting persistent Bluetooth to work, however we should be able to complete that with the extra slack time we have.

For next week, I will be working with Janet on making the Bluetooth connection persistent, so the user does not need to reconnect to check their items. I will also be performing distance testing to determine how well our system gates items inside versus outside the backpack.

Leave a Reply

Your email address will not be published. Required fields are marked *