feat(gitlab): two-way sync between Huly and GitLab

[robertozimek]

This adds a GitLab integration, built the same way as the GitHub one. It keeps issues, comments, merge requests, reviews and images in sync between Huly and GitLab, in both directions.

Before you deploy:

• Run the account migration first. It adds GitLab as a login type.
• The GitLab service has two new settings: GITLAB_ALLOWED_HOSTS, for GitLab servers on a private network, and GITLAB_REQUEST_TIMEOUT_MS.

It also fixes the front-end build on develop, which failed because the language files couldn't be loaded.

The steps for testing by hand are in services/gitlab/pod-gitlab/Readme.md.

[ArtyomSavchenko]

Hi @robertozimek
Thank you for the contribution.
Please take a look at review comments:

---

Should fix

1. The pod trusts Huly document fields that a client may be able to modify (medium–high)

GitlabIntegration documents live in core.space.Configuration. Their host and connectedBy fields are marked @ReadOnly(), which in Huly is a UI hint only; the server does not enforce it. The only server trigger in this PR narrows the broadcast of DocSyncInfo and GitlabUpload. I found no write protection for these documents.

worker.integrationApi() (pod-gitlab/src/worker/worker.ts) builds its client from the document:

const record = await this.userRecord(integration.connectedBy)
return record === undefined ? undefined : this.api(integration.host, record.token)

It never checks that record.host === integration.host. The same pattern appears in service.ts (resolveRepository, removeIntegration, the refresh loop). By contrast, userApi() and apiFor() in the same file do check own.host !== integration.host, so the check is simply missing on the integration-token path.

If a regular workspace member can update such a document, they could:

• Exfiltrate a token: set host to a server they control. HostGuard only blocks private addresses, so a public host passes, and the pod sends Authorization: Bearer <victim's OAuth token> to it.
• Act as another user: set connectedBy to another member's social id, so the pod reads or writes GitLab with that member's token.
• Reach other projects: change projectId on GitlabIntegrationRepository to point at another project the token owner can access.

2. /api/v1/refresh is open to any workspace member (low–medium)

The route only verifies the token and that the social id belongs to the caller. It then iterates every integration in the workspace as System, using each owner's token, and calls GitLab. There is no rate limit, so any member can trigger repeated sweeps and burn other members' GitLab rate limits. Restrict it to Maintainer and add a rate limit.

3. Unauthenticated request bodies are parsed before the webhook token is checked (low–medium)

server.ts registers bp.json({ limit: '10mb' }) globally, so up to 10 MB is parsed for every request before x-gitlab-token is verified. Mount the webhook route ahead of the global parser, check the header first, then parse with its own limit.

4. DNS rebinding gap in HostGuard (low)

HostGuard resolves the hostname, caches the result for 60 s, and fetch then resolves it again. A host that answers with a public address for the check and a private one for the request would pass. Pin the validated address in the request's lookup. Until then, document GITLAB_ALLOWED_HOSTS as recommended for production.

---

Nits

• window.open(authorizeUrl) has no noopener (gitlab-resources/src/utils.ts), so the GitLab page gets window.opener. The URL comes from the pod and its scheme is not checked on the client; safeHttpUrl already exists.
• OAuth state is replayable within its 10-minute TTL. The nonce is generated but never checked or consumed. Impact is low, because the GitLab code is single-use and the state is bound to the user and workspace. Either drop the nonce or track it.
• cors() allows any origin. Harmless today (auth is by token in the body, no cookies), but restricting it to the front URL costs nothing.
• hostKey ignores the URL scheme, so http://x and https://x share one identity key. Only relevant with GITLAB_ALLOW_INSECURE_HOSTS, which is dev-only.
• No strength check for WEBHOOK_SECRET and SERVER_SECRET. The dev compose overlay defaults both to secret. A startup warning for weak values outside insecure mode would be cheap insurance.

[robertozimek]

Thanks so much for taking the time to review this, @ArtyomSavchenko! I think this project is awesome and I'm glad to be contributing. I've implemented all the changes, including the nits.

[ArtyomSavchenko]

Hi @robertozimek
Thank you for the kind words.
Could you also take a look at the following recommendations?

Should fix

Any workspace member can bypass the "connector or maintainer" check when enabling a repository.

1. GitlabIntegrationMiddleware lets a User-role member write enabled and gitlabProject on GitlabIntegrationRepository. The sync worker activates a repository on those fields alone (worker.ts:643), so a raw transaction skips the check in repository-enable.
2. Require Maintainer (or Owner) for these fields, or make the worker ignore repositories the service did not enable itself.
3. Add a middleware test that covers this case.

Reuse existing code

Swapping the SSRF guard for @hcengineering/safe-fetch removes about 330 lines of code and about 340 lines of tests; four smaller replacements follow.

Replace host-guard.ts and gitlab/fetch.ts with safe-fetch

PR #49 is already in develop and registered in rush.json. GitLab would be its first production consumer, so coordinate with the #49 author. Required adaptations:

1. In GitlabApi.send, pass redirect: followRedirects ? 'follow' : 'error' and maxRedirects: 3. safe-fetch follows redirects by default.
2. Keep GITLAB_ALLOWED_HOSTS exclusive with a small wrapper. In safe-fetch, allowlist only grants exceptions to the blocked ranges.
3. Map dev mode (GITLAB_ALLOW_INSECURE_HOSTS) to allowHttp: true plus an allowlist of private CIDRs and localhost.
4. Set maxBodyBytes explicitly. The default is 10 MiB per response and MR diffs can be larger.
5. Replace hostGuard.assertAllowed in saveApp with validateUrl and resolveAndCheck.
6. Adapt error handling and tests to SafeFetchError codes.
7. Add 100::/64 to BLOCKED_IPV6_RANGES in safe-fetch, since GitLab's guard blocks it.

Other replacements

Custom code	Replace with	Saves	Notes
ttl-cache.ts (pod)	lru-cache	about 50 lines + tests	Already ^11.1.0 in 5 packages. Check how to inject the clock for tests.
hunk.ts	parseDiff from diffview-resources	about 50 lines	Export it from the package index and confirm it can be imported from the front end.
createTextCache (UI)	lru-cache	about 35 lines	Low priority: lru-cache is not yet used in front-end code.