mkdocs-material & encrypted search: is it possible to leverage material's custom_dir to deploy your patched index.ts?

[ryran]

Hey there! I'm less than 12 hours into my journey of exploring mkdocs and mkdocs-material and this awesome plugin.

I read the documentation at Search index encryption for mkdocs-material. I'm doing this all via a GitLab pipeline, so I wasn't quite sure what to do until I read about material's support for theme extension via the custom_dir option.

So here's what I did:

1. Downloaded material_browser_request9_4p.patch
2. Downloaded index.ts from the latest material release and saved it to my git repo as overrides/assets/javascripts/browser/request/index.ts
3. Patched said file successfully
4. Updated my mkdocs.yml to include custom_dir: overrides under theme
5. Committed and pushed my changes to trigger the ci job that runs mkdocs

Oh PS: Here's my plugin config:

plugins:
  - search
  - roamlinks
  - callouts
  - encryptcontent:
      webcrypto: true
      search_index: dynamically
      encrypted_something:
        md-nav: [nav, class]
        md-footer__inner: [nav, class]
      password_inventory:
        ...

Unfortunately, search still doesn't work for encrypted pages, even after decrypting.

Since I'm so brand-new to all of this, I couldn't help but ask: do you have any suggestions about what I might be doing wrong or what a better approach might be?

[unverbuggt]

The javascript code of material is written in typescript. It needs to be compiled to javascript with nodejs to work in a browser. The process is explained here.

The only solution we came up with, so far, is to modify the typescript source code and build a custom version of material-mkdocs that supports dynamic search decryption (see #52).

There is a new search for material currently in development. Maybe this will cache the search somewhere where we could modify it externally via the plugins javascript code.

[squidfunk]

Author of Material for MkDocs here. Note that it is not a good idea to store the search index in session storage, due to limitations of session storage. It's a better idea to provide appropriate cache headers, so the browser just fetches the index from cache. Any caching that is coming with the new search will very likely (haven't started working on caching, but this is my guess) be based on indexed data, so too late for decryption. However, we may have the ability to provide a mechanism to map the search index prior to the indexing phase, but that's currently not a priority. We can add this later at any time.

[unverbuggt]

Hi,

yes, the limitation is 5MB of search index. I know this is only a bad hack...

Currently, we also encrypt the location of a search entry (additional to title and text), but this can be undone (or worked out differently).
If mkdocs-material would provide an externally callable function that lets external scripts update the title and text of a location, that would be great.