backport algolia search support from buildkite.com #681
Conversation
A few weeks ago, we added search to https://buildkite.com/docs, using algolia [1]. We're in the process of extracting the docs content to be hosted as a dedicated, self-contained rails app that's deployed to fargate. Before that migration can be made live for users, we first need to backport the new search functionality to this app so it'll remain available for users. Most of this is copied as-is from its original home, and it seems to work. I've opted to store the algolia config values in SSM for consistency. On the one hand their public values that can be seen in the page source, but on the other hand they're config and it feel weird to just store them in a view. I'm happy to reconsider if anyone feels strongly. I also had to hack the CSP settings so the algolia JS would load. I haven't done much work with CSP so I assume I've opened a big security hole and would love someone to take a look at it. [1] https://www.algolia.com/
|
Tagging @keithpitt (for algolia experience) and @toolmantim (for CSP wizardry) |
| #policy.script_src :self, :unsafe_eval, Matomo::URL, :unsafe_inline, :strict_dynamic, :report_sample, :https, :http | ||
| policy.script_src :unsafe_eval, :unsafe_inline, :strict_dynamic, :report_sample, :https, :http | ||
| end | ||
| policy.connect_src 'https://*.algolia.net', 'https://*.algolianet.com' |
There was a problem hiding this comment.
I assume my changes here are wrong 🙈
There was a problem hiding this comment.
That looks okay to me? Anything that you’re particularly worried about?
There was a problem hiding this comment.
I’m spin this up and see if we can find a way to have a stricter CSP, given how tiny the docs app is.
There was a problem hiding this comment.
Anything that you’re particularly worried about?
Just that I don't understand CSP. I can see a lot of care went into crafting the CSP rules on buildkite.com, and the rules that I cargo-culted into here had very little care put into them.
I’m spin this up and see if we can find a way to have a stricter CSP
I'm not 100% confident what makes a CSP more or less strict. Would you have time for a quick pairing session on this?
|
Amazing @yob! ❤️ |
| #policy.script_src :self, :unsafe_eval, Matomo::URL, :unsafe_inline, :strict_dynamic, :report_sample, :https, :http | ||
| policy.script_src :unsafe_eval, :unsafe_inline, :strict_dynamic, :report_sample, :https, :http | ||
| end | ||
| policy.connect_src 'https://*.algolia.net', 'https://*.algolianet.com' |
There was a problem hiding this comment.
I’m spin this up and see if we can find a way to have a stricter CSP, given how tiny the docs app is.
Tim and I just spent some time pairing on the best way to get algolia backported from bk/bk to this app. We explored leaving CSP enforced, but that requires allowing `unsafe_eval` in production and that's not ideal. It turns out CSP on bk/bk is in report-only mode as well, and docsearch is violating it (with a report) each time someone searches. So for now, we've configured this appto behave the same way. We'd love to start enforcing CSP on the docs app, but there's been little movement on docsearch adapting to be more CSP friendly (see algolia/docsearch#773). Algolia have an alternative JS library that is CSP friendly and we'd love to use it. Maybe that's our best path to enforcing CSP? https://www.algolia.com/doc/guides/building-search-ui/what-is-instantsearch/js/
|
@toolmantim and I just spent some time pairing on the best way to get algolia backported from bk/bk to this app without violating CSP rules. We explored leaving CSP enforced, but that requires allowing So for now, we've configured this appto behave the same way. We'd love to start enforcing CSP on the docs app, but there's been little movement on docsearch adapting to be more CSP friendly (see algolia/docsearch#773). Algolia have an alternative JS library that is CSP friendly and we'd love to use it. Maybe that's our best path to enforcing CSP? https://www.algolia.com/doc/guides/building-search-ui/what-is-instantsearch/js/ |
There was a problem hiding this comment.
InstantSearch.js is something @scopegate has been working with recently too, so there's definitely a path forward there with an enforced CSP I reckon 👌🏼
A few weeks ago, we added search to https://buildkite.com/docs, using algolia.
We're in the process of extracting the docs content to be hosted as a dedicated, self-contained rails app that's deployed to fargate. Before that migration can be made live for users, we first need to backport the new search functionality to this app so it'll remain available for users.
Most of this is copied as-is from its original home, and it seems to work.
I've opted to store the algolia config values in SSM for consistency. On the one hand their public values that can be seen in the page source, but on the other hand they're config and it feel weird to just store them in a view. I'm happy to reconsider if anyone feels strongly.
I also had to hack the CSP settings so the algolia JS would load. I haven't done much work with CSP so I assume I've opened a big security hole and would love someone to take a look at it.