Adding encrypted INCY links - #53
Conversation
Greptile SummaryThis PR moves INCY encrypted deep-link generation entirely to the frontend by introducing a
Confidence Score: 3/5The docker-compose change introduces a hard runtime dependency on a pre-existing external network, which will break The docker-compose
Important Files Changed
Sequence Diagram%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Browser
participant InstallationGuideConnector
participant encryptLink as encryptLink (@densds/link-encoder)
participant OS as OS/App Handler
Browser->>InstallationGuideConnector: Mount (subscriptionUrl, username)
InstallationGuideConnector->>InstallationGuideConnector: "incyCryptLoading = true"
InstallationGuideConnector->>encryptLink: "encryptLink(subscriptionUrl, { name })"
encryptLink-->>InstallationGuideConnector: incy://crypt1/... (or error)
InstallationGuideConnector->>InstallationGuideConnector: "setIncyCryptLink(link) / incyCryptLoading = false"
Browser->>InstallationGuideConnector: User clicks INCY button
alt incyCryptLink is undefined
InstallationGuideConnector-->>Browser: Show error notification
else incyCryptLink is ready
InstallationGuideConnector->>Browser: "window.location.href = incyCryptLink"
Browser->>OS: Deep link handoff (incy://)
end
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Browser
participant InstallationGuideConnector
participant encryptLink as encryptLink (@densds/link-encoder)
participant OS as OS/App Handler
Browser->>InstallationGuideConnector: Mount (subscriptionUrl, username)
InstallationGuideConnector->>InstallationGuideConnector: "incyCryptLoading = true"
InstallationGuideConnector->>encryptLink: "encryptLink(subscriptionUrl, { name })"
encryptLink-->>InstallationGuideConnector: incy://crypt1/... (or error)
InstallationGuideConnector->>InstallationGuideConnector: "setIncyCryptLink(link) / incyCryptLoading = false"
Browser->>InstallationGuideConnector: User clicks INCY button
alt incyCryptLink is undefined
InstallationGuideConnector-->>Browser: Show error notification
else incyCryptLink is ready
InstallationGuideConnector->>Browser: "window.location.href = incyCryptLink"
Browser->>OS: Deep link handoff (incy://)
end
Reviews (2): Last reviewed commit: "Transferring encrypted links from the ba..." | Re-trigger Greptile |
| case 'subscriptionLink': { | ||
| if (!formattedUrl) return | ||
|
|
||
| window.open(formattedUrl, '_blank') | ||
| window.location.href = formattedUrl | ||
| break |
There was a problem hiding this comment.
subscriptionLink now navigates in-place for all subscription buttons
The change from window.open(formattedUrl, '_blank') to window.location.href = formattedUrl applies to every button with type 'subscriptionLink', not just INCY ones. Any subscription-link button that resolves to a regular https:// URL will now silently navigate the current tab away from the subscription page, discarding the loaded session. Only deep-link protocols (e.g. incy://, vpn://) are unaffected because the browser hands them off to the OS without actually navigating. If the intent is to support deep links from a subscriptionLink button, a narrower guard (e.g. checking the resulting URL protocol) would prevent the regression for https links.
| useEffect(() => { | ||
| let cancelled = false | ||
| setIncyCryptLoading(true) | ||
|
|
||
| // name is capped at 128 chars per @densds/link-encoder's encryptLink contract | ||
| const name = subscription.user.username.slice(0, 128) | ||
|
|
||
| encryptLink(subscriptionUrl, { name }) | ||
| .then((link) => { | ||
| if (!cancelled) setIncyCryptLink(link) | ||
| }) | ||
| .catch((e) => { | ||
| console.error('Failed to generate INCY link', e) | ||
| }) | ||
| .finally(() => { | ||
| if (!cancelled) setIncyCryptLoading(false) | ||
| }) | ||
|
|
||
| return () => { | ||
| cancelled = true | ||
| } | ||
| // eslint-disable-next-line react-hooks/exhaustive-deps | ||
| }, [subscriptionUrl, subscription.user.username]) |
There was a problem hiding this comment.
encryptLink runs unconditionally even when INCY is not configured
encryptLink is called on every mount regardless of whether any button in the current config actually uses {{INCY_CRYPT1_LINK}}. For the majority of users who have no INCY button, this triggers an unnecessary async crypto operation and briefly sets incyCryptLoading to true. If the call also fails (network issue, library error), incyCryptLink stays undefined and any user who somehow triggers the button sees an error notification instead of a graceful no-op. Guarding the effect with a check before calling encryptLink avoids the waste and prevents a spurious loading flash for non-INCY deployments.
| }, | ||
| "dependencies": { | ||
| "@gfazioli/mantine-spinner": "^2.3.9", | ||
| "@densds/link-encoder": "^2.0.0", |
There was a problem hiding this comment.
Unverified npm package
@densds/link-encoder from PR author
@densds/link-encoder is published under the same namespace as this PR's author (densds) and returns no results in standard npm-registry searches. Unlike the existing @kastov/cryptohapp dependency (which is independently verifiable), this package has no visible GitHub repository, changelog, or community adoption. Since it handles subscription URL encryption on the client side — processing real user subscription URLs — it sits in a sensitive position. Before merging, the project maintainers should verify the package's source code and confirm its npm publish provenance matches the author's identity.
|
@greptile-apps re-review |
…render Telegram Desktop's embedded WebView2 blocks navigation to custom schemes (happ://, incy://) even on a fully synchronous click. When the page is opened as a Telegram Mini App, immediately hand off to the system browser via Telegram.WebApp.openLink() when platform is 'tdesktop', where deep links work normally. No-op everywhere else, including mobile clients.
window.location.href was silently breaking the OS hand-off for custom-scheme deep links inside Telegram's mobile Mini App WebView. window.open, called synchronously with no async gap, is the pattern already validated in the sibling remnawave-shopbot project for the same happ:// / incy:// links. Regular http(s) subscriptionLink buttons also stay in a new tab now, same fix as before, just via a single code path instead of a protocol branch.
Moved subscription encryption from the backend to the frontend, modified the original INCY library, and now all logic is moved to the frontend without public API endpoints