Docs are served only over HTTP

[Yoshanuikabundi]

The OpenMM User's Manual, Python API docs, C++ API docs, and Developer Guide are all served over HTTP rather than HTTPS. We should serve via HTTPS and redirect HTTP requests to HTTPS.

[jchodera]

Yep! Any idea how we fix this? I couldn't figure it out.

The docs are served from an S3 bucket, and the website is now served from GitHub Pages.

[Yoshanuikabundi]

Haven't used S3 before, but apparently it doesn't directly support HTTPS and we'd need to go through CloudFront. It might also be possible to set Jekyll up to clone the OpenMM repo, run Sphinx/Doxygen and serve the docs with the website, or we could just use ReadTheDocs or something similar. I haven't quite got my head around how the docs are built and served yet but I've got the sense that simplification might be good here.

[raimis]

Maybe a simpler approach is:

• Run Sphinx/Doxygen with GitHub Actions
• Commit the generated HTML files into a branch
• Serve the docs with GitHub Pages from that branch

Or, alternatively, serve the docs from ReadTheDocs.

[mattwthompson]

This is still an issue - is simply doing everything on RTD too heavy a lift?

[Yoshanuikabundi]

OpenMM's docs are split into (at least) 3 Sphinx projects that I believe would have to be combined to get it on RTD. It also relies on doxygen and auto-generated code (and cmake I think?), and getting RTD to generate old versions would be... a task. I think it would be possible but its definitely a significant lift. Using GitHub pages would be comparatively simple I think, but has the significant downside of requiring the rendered docs to be downloaded with every clone and every pull since a new version is published (we do this at openff-docs and its not the worst but its not ideal). Having a different repo store the rendered docs and appropriate workflows would probably be possible. Using a general purpose hosting platform like Vercel might be more practical.

[mattwthompson]

Perhaps there's a simpler way to get this all onto HTTPS, then

Accessing static, read-only documentation pages isn't a use case in which security is a high priority, but it's becoming more and more of a hassle over time to have some of our links point to HTTP pages

[jchodera]

Copying in @peastman.

The docs are currently served from an AWS s3 bucket. s3 buckets do not support https. Instead, they recommend serving from s3 via cloudfront.

This could be a reasonable approach if it doesn't cost much, since the OpenMM AWS account has been paid by my personal credit card for the last few years without any hope of reimbursement. If someone was willing to investigate, we could likely use this solution---I'd be happy to help with AWS credentials.

Longer term, as we're also working to hire an OpenMM community dev via OMSF with the new OpenMM funding, it would be useful if OMSF could help coordinate community usability and interoperability issues like this. Would be happy to chat about that!

[peastman]

Pricing is at https://aws.amazon.com/cloudfront/pricing/. I'd be surprised if we need more than the free tier. It includes 1 TB of data transfer out to the internet and 10,000,000 HTTP or HTTPS requests per month. We should be careful of what happens when you exceed that though. I'd want to be sure someone couldn't run up massive charges for us by writing a script that hammers the website!