Troubleshooting Common Web Issues
Cross-Origin Resource Sharing (CORS) is a security standard that primarily helps protect users of websites from experiencing malicious content. A core concept of web security is the "same-origin policy," which says that a page at app.example.com can trust content from the same origin (e.g., app.example.com/api/v1/resource ), and that the API can trust requests from that page.
Websites often use data from other domains/origins, such as loading images from other sources. As a user of Aquarium, you're likely providing images from a source that isn't aquariumlearning.com, such as a cloud bucket URL or your own image server. Because this is so common for images, the CORS specs say that if you're only drawing an image onto the page, you don't have to do anything special.
But, if we want to access any values in application logic (e.g., semantic segmentation masks, lidar point clouds, etc.), both the browser app and the server need to set HTTP headers that say they mutually agree that these Cross-Origin requests are ok.
Here are some configurations for common data sources. If you have a setup that doesn't match one of these, reach out to us and we'll work with you to get going!
Log into your cloud console and navigate to the S3 Buckets page:
Click into the bucket, and navigate to the "Permissions" tab:
Scroll to the bottom, and you'll see an area to provide a CORS configuration:
If you already see a configuration json object, you will want to add the following configuration to the existing list, otherwise you'll replace your existing settings.
Click "Edit", and enter the following configuration:
[{"AllowedHeaders": ["*"],"AllowedMethods": ["GET","HEAD"],"AllowedOrigins": ["https://illume.aquariumlearning.com/*"],"ExposeHeaders": [],"MaxAgeSeconds": 3600}]
These settings state that your S3 bucket should allow reads (GET and HEAD) from secure connections to Aquarium. After saving, you should see the following:
Coming soon! In the meantime, please reach out and we'll get you all set up.
Coming soon! In the meantime, please reach out and we'll get you all set up.
Ensure you have the gsutil command line utility installed. If you do not, installation instructions are available here.
Run the following command to verify that there are no pre-existing cors configurations:
$ gsutil cors get gs://aq-test-private-bucketgs://aq-test-private-bucket/ has no CORS configuration.
If you instead get back a configuration json object, you will want to add the following configuration to the existing list, otherwise you'll replace your existing settings.
Create a file called bucket-cors.json, with the following content:
[{"maxAgeSeconds": 3600,"method": ["GET","HEAD","OPTIONS"],"origin": ["https://illume.aquariumlearning.com"],"responseHeader": ["*"]}]
These settings state that your GCS bucket should allow reads (GET and HEAD) from secure connections to Aquarium.
Then, run the following command to apply these cors settings to your bucket:
$ gsutil cors set bucket-cors.json gs://your-bucketSetting CORS on gs://your-bucket/...
You should be all set!
Coming soon! In the meantime, please reach out and we'll get you all set up.
You may need to make tweaks to this based on your exact setup, but here's a baseline implementation of adding necessary CORS headers to an nginx proxy, including properly handling pre-flighted CORS requests.
server { # proxy server to add cors headerslisten 3001;server_name localhost;​set $cors_origin '';set $cors_cred '';​if ($http_origin ~ '^https?://(localhost:3000|illume\.aquariumlearning\.com)$') {set $cors_origin $http_origin;set $cors_cred true;}​add_header 'Access-Control-Allow-Origin' $cors_origin always;add_header 'Access-Control-Allow-Credentials' $cors_cred always;add_header 'Access-Control-Allow-Methods' 'GET,POST,HEAD,OPTIONS' always;add_header 'Access-Control-Allow-Headers' '*' always;add_header 'Access-Control-Expose-Headers' '*' always;add_header 'Access-Control-Max-Age' 3600 always;add_header 'Content-Type' '*' always;if ($request_method = 'OPTIONS') {return 204 no-content;}​location / {proxy_pass http://localhost:3002;}}
Coming soon! In the meantime, please reach out and we'll get you all set up.
For more reading, feel free to check out the Mozilla docs.​
"Mixed Content" occurs when the main web page uses a secure (HTTPS) connection, but it tries to load content from an insecure (HTTP) connection.
Historically, browsers have differentiated between passive mixed content and active mixed content. Passive content doesn't affect javascript behavior, and is defined as images, video, and audio content. Active content includes everything else that could potentially change how the page behaves. The general consensus was that active mixed content was always bad, but passive mixed content is acceptable.
In 2020, Chromium based browsers (Google Chrome + Microsoft Edge) have started blocking passive mixed content by default. Because Aquarium serves the web app over a secure connection, if you provide your image data using an image server or proxy without SSL / HTTPS support, attempts to load the image will be blocked.
The best option is to enable SSL / HTTPS on your side, but that can take a decent amount of effort. The other, often easier, option is to configure your browser to allow the Aquarium App to accept images from HTTP data sources:
On the https://illume.aquariumlearning.com/ page, click on the lock icon and navigate to the "Site settings".
Scroll down until you see the site settings for "Insecure content", which tells Chrome how to treat mixed content on this website:
Update that field to "Allow" for the Aquarium App:
After opening a new tab, you should no longer encounter Mixed Content errors!
Coming soon! In the meantime, please reach out and we'll get you all set up.
For more reading, check out these two blog posts by the Chromium team:
​What is mixed content?​
