Federated search

[rosemcc]

Feature

Include results from the Staff Intranet in the ResearchHub search results UI

Description

The Intranet contains documents that overlap with the material the Research Hub provides. It is helpful to be able to include results from the Intranet in the Research Hub search, enabling users to navigate directly to these documents from the Research Hub search results page.

Intranet search results are accessed via a Swiftype API, within a collection called "Staff Intranet". This feature provides an update to the search page UI so logged-in users can choose to view the Intranet results, as well as the implementation of the backend API wrapper to access the Swiftype API securely. More information around the technical and security considerations of adding this feature can be found here.

Solution

Swiftype API Wrapper - Lambda function

A new endpoint has been added to the Hub-Search-Proxy lambda function which acts as a middleware between the UI and the Swiftype API. The purpose of this is to provide a secure way to access the Intranet search results, which must be behind SSO, as well as keeping the Swiftype API key in a secure location which will never be exposed to the frontend.

The new endpoint function is implemented in a separate handler file (uoasearch.js). The endpoint path is /uoasearch, which is configured in the serverless.yml, along with an API Gateway Authorizer to enable Cognito user pool authorization of requests to the endpoint. Requests must contain a valid auth token or they will be blocked by API Gateway. Requests are authorized by checking the user is in the valid access group to be able to view Staff Intranet data.

Search UI Changes

A tabbed interface has been added to the search results page using Angular Material Tabs component. ResearchHub results are shown in the default tab, and Staff Intranet results are shown (if the user is logged in) in a second tab, as a separate list. Results are only returned when a search query is present. Search filters are not applied on the Intranet results.

New components/services:

• IntranetSearchService
• IntranetSearchComponent
• IntranetSearchResultsListComponent

Cloudfront Function change

• updated CSP to allow the new search endpoint

Screenshots

Before

After

Staff Intranet tab:

Testing

research-hub-web

IntranetSearchComponent:

• should create
• Initial search properties should be undefined
• search should update search variables
• should not call intranet search if not logged in

IntranetSearchResultsListComponent:

• should create
• should show skeleton when loading
• should show 1 results card for each search result

IntranetSearchService

• should be created
• should make a POST request and return search result

hub-search-proxy

• POST uoasearch request returns a response
• POST uoasearch request with invalid sort option returns an error

Have the changes been checked in the following browsers?

• Chrome
• Safari
• Firefox
• Edge

[rosemcc]

@Trombach have addressed most comments, just haven't managed to fix the sticky filter bar. Also added some (very) basic error handling for if there's any issue with fetching search results. The error handling could be improved with adding more informative message for the user, but for now I think it is enough.

[rosemcc]

@Trombach also, if you have time could you please do a quick check of the interface in Safari? 🙏

In general, the fix is to explicitly define a permissions block in the workflow (either at the top level or per job) that grants only the minimal required scopes for the job. For a lint-only Node/Angular job that just checks out code and runs npm/ng lint, read-only access to repository contents is sufficient.

The best fix here is to add a workflow-level permissions block just after the name: Lint line, setting contents: read. This will apply to all jobs in this workflow (currently just run-linters) and ensures the GITHUB_TOKEN cannot perform write operations. No other scopes (such as pull-requests or issues) are required by the shown steps, so they should not be added.

Concretely, in .github/workflows/linting.yml, insert:

permissions:
  contents: read

between lines 1 and 3 (after name: Lint and before the on: block). No imports or additional definitions are needed.

In general, the fix is to explicitly declare a permissions block in the workflow (either at the root level or for the specific job) that grants only the minimal access required. Since this workflow only checks out the code and talks to Sentry, it needs at most read access to repository contents and does not appear to require write access to any GitHub resources.

The best minimal change without altering existing functionality is to add permissions: contents: read at the job level for sentry-release. This limits the GITHUB_TOKEN to read-only access to repository contents for that job, regardless of the repository’s default token permissions. Concretely, in .github/workflows/sentry.yml, under jobs: sentry-release: name: Create Sentry Release, add a permissions: block aligned with runs-on: and steps:. No imports or other definitions are needed, as this is purely a YAML configuration change.

In general, to fix log injection you should sanitize or normalize user input before writing it to logs. For plain text logs, this typically means removing or replacing newline (\n) and carriage return (\r) characters (and optionally other control characters) from any user-controlled values. It also helps to clearly label logged user input.

For this specific case in hub-search-proxy/handler.js, the safest minimal change is to avoid logging event.body verbatim. Instead, create a sanitized version that strips newline and carriage-return characters before logging. A concise approach is to convert event.body to a string (to avoid issues if it’s not already) and then call replace with a regular expression like /[\r\n]/g or a broader control-character pattern. Then log that sanitized value. This keeps existing behavior (logging the raw request body) while preventing log entries from being split or forged by malicious content.

Concretely, within module.exports.search right before the log or replacing the current log line, introduce a small sanitization step:

• Define const bodyForLog = String(event.body).replace(/[\r\n]/g, ' ');
• Use bodyForLog in the console.log message: console.log(`Received query: ${bodyForLog}`);

This change only touches the shown snippet in hub-search-proxy/handler.js, requires no new helper functions, and no new imports.

In general, fix log injection by sanitizing user-controlled values before logging them: remove or escape newline (\n) and carriage return (\r) characters (and optionally other control characters), and clearly label the user input in the log message. This prevents an attacker from breaking the log format or injecting fake entries while preserving useful context.

For this specific file, the minimal and safest change is to avoid logging event.body raw. A good approach is:

• Create a sanitized version of event.body by converting it to a string (in case it isn’t already) and removing \r and \n.
• Log only that sanitized value.
• Keep the rest of the logic unchanged.

Concretely:

• In hub-search-proxy/uoasearch.js, above the existing console.log on line 12, introduce a new variable, e.g. const safeBodyForLog = String(event.body).replace(/[\r\n]/g, '');.
• Replace the existing console.log(\Received query: ${event.body}`);withconsole.log(`Received query: ${safeBodyForLog}`);. No new imports or dependencies are needed since we rely on built-in Stringandreplace`.

Generally, to fix log injection, any data that may originate from users (directly or indirectly) should be sanitized before being written to logs. For plain-text logs, it is usually sufficient to strip carriage returns and newlines from the string representation of the data, and to clearly mark user-controlled content. Instead of logging raw objects that may stringify to multi-line strings, log a sanitized subset such as the error name and a cleaned-up message.

In this specific case, we should avoid passing the raw error object directly to console.log. Instead, in hub-search-proxy/uoasearch.js inside the catch block, we can construct a safe log line that includes error.name and a sanitized version of error.message, with \r and \n removed. We can also add a small helper within this file to sanitize strings for logging, or just perform inline replace operations. No changes are needed in helpers.js. Concretely: modify line 82 to log a single-line, sanitized message, and avoid logging arbitrary additional properties or stacks that may contain newlines. We do not need extra imports; we can rely on String.prototype.replace.