Currently our scripts use curl to query the SiteSearchData WDK instance 12 times per run. Since we don't use the returned guest token in subsequent requests, each run creates a 12 distinct new guest users. We should cut this down to 1 by querying the project service "/" first using a curl cookie jar (temp file) and use the same cookie jar in all subsequent requests, then remove the tmp file.
Related: SiteSearchData's WDK currently needs a more privileged clientId than it probably should since it can create guests at will. If, rather than use "this" WDK to get the guest token, we use e.g. https://veupathdb.org/veupathdb/service, and use the guest token returned by that service for subsequent calls to the SiteSearchData WDK, then that WDK will only need a client ID able to verify tokens (like "veupathdbService") rather than create new guest tokens. This means our more sensitive client secret can be shared less widely.
Currently our scripts use curl to query the SiteSearchData WDK instance 12 times per run. Since we don't use the returned guest token in subsequent requests, each run creates a 12 distinct new guest users. We should cut this down to 1 by querying the project service "/" first using a curl cookie jar (temp file) and use the same cookie jar in all subsequent requests, then remove the tmp file.
Related: SiteSearchData's WDK currently needs a more privileged clientId than it probably should since it can create guests at will. If, rather than use "this" WDK to get the guest token, we use e.g. https://veupathdb.org/veupathdb/service, and use the guest token returned by that service for subsequent calls to the SiteSearchData WDK, then that WDK will only need a client ID able to verify tokens (like "veupathdbService") rather than create new guest tokens. This means our more sensitive client secret can be shared less widely.