Reddit Programming
212 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
How do you build serious extension features within the constraints of VS Code’s public APIs?
https://www.reddit.com/r/programming/comments/1qcuy8d/how_do_you_build_serious_extension_features/

<!-- SC_OFF -->Most tools don’t even try. They fork the editor or build a custom IDE so they can skip the hard interaction problems. I'm working on an open-source coding agent and was faced with the dilemma of how to render code suggestions inside VS Code. Our NES is a VS Code–native feature. That meant living inside strict performance budgets and interaction patterns that were never designed for LLMs proposing multi-line, structural edits in real time. In this case, surfacing enough context for an AI suggestion to be actionable, without stealing attention, is much harder. That pushed us toward a dynamic rendering strategy instead of a single AI suggestion UI. Each path gets deliberately scoped to the situations where it performs best, aligning it with the least disruptive representation for a given edit. If AI is going to live inside real editors, I think this is the layer that actually matters. Full write-up in in the blog <!-- SC_ON --> submitted by /u/National_Purpose5521 (https://www.reddit.com/user/National_Purpose5521)
[link] (https://docs.getpochi.com/developer-updates/dynamic-rendering-stratergies-for-ai-edits/) [comments] (https://www.reddit.com/r/programming/comments/1qcuy8d/how_do_you_build_serious_extension_features/)
Responsible disclosure of a Claude Cowork vulnerability that lets hidden prompt injections exfiltrate local files by uploading them to an attacker’s Anthropic account
https://www.reddit.com/r/programming/comments/1qdg7i4/responsible_disclosure_of_a_claude_cowork/

<!-- SC_OFF -->From the article: Two days ago, Anthropic released the Claude Cowork research preview (a general-purpose AI agent to help anyone with their day-to-day work). In this article, we demonstrate how attackers can exfiltrate user files from Cowork by exploiting an unremediated vulnerability in Claude’s coding environment, which now extends to Cowork. The vulnerability was first identified in Claude.ai chat before Cowork existed by Johann Rehberger, who disclosed the vulnerability — it was acknowledged but not remediated by Anthropic. <!-- SC_ON --> submitted by /u/sean-adapt (https://www.reddit.com/user/sean-adapt)
[link] (https://www.promptarmor.com/resources/claude-cowork-exfiltrates-files) [comments] (https://www.reddit.com/r/programming/comments/1qdg7i4/responsible_disclosure_of_a_claude_cowork/)
Programmer in Wonderland
https://www.reddit.com/r/programming/comments/1qdglkv/programmer_in_wonderland/

<!-- SC_OFF -->Hey Devs, Do not become The Lost Programmer in the bottomless ocean of software abstractions, especially with the recent advent of AI-driven hype; instead, focus on the fundamentals, make the magic go away and become A Great One! <!-- SC_ON --> submitted by /u/BinaryIgor (https://www.reddit.com/user/BinaryIgor)
[link] (https://binaryigor.com/programmer-in-wonderland.html) [comments] (https://www.reddit.com/r/programming/comments/1qdglkv/programmer_in_wonderland/)
The surprisingly tricky parts of building a webhook debugger: SSE memory leaks, SSRF edge cases, and timing-safe auth
https://www.reddit.com/r/programming/comments/1qdof8e/the_surprisingly_tricky_parts_of_building_a/

<!-- SC_OFF -->I've been working on a webhook debugging tool and wanted to share some of the non-obvious engineering problems I ran into. These aren't specific to my project—they're patterns that apply to any Node.js service handling real-time streams, user-supplied URLs, or API authentication. 1. SSE connections behind corporate proxies don't work (until you pad them) Server-Sent Events seem simple: open a connection, keep it alive with heartbeats. But many users reported 10+ second delays before seeing any data. The cause: Corporate proxies and Nginx buffer responses until they hit a size threshold (often 4KB). Your initial : connected\n\n message is 13 bytes—nowhere close. The fix: javascript res.setHeader("X-Accel-Buffering", "no"); res.setHeader("Content-Encoding", "identity"); // Disable compression res.write(": connected\n\n"); res.write(`: ${" ".repeat(2048)}\n\n`); // 2KB padding forces flush Also, one setInterval per connection is a memory leak waiting to happen. With 500 connections, you have 500 timers. A single global timer iterating a Set cut our memory usage by ~40%. 2. String comparison leaks your API key (timing attacks) If you're validating API keys with ===, you're vulnerable. The comparison returns early on the first mismatched character, so an attacker can measure response times to guess the key character-by-character. The fix: crypto.timingSafeEqual ensures constant-time comparison: javascript const safeBuffer = expected.length === provided.length ? provided : Buffer.alloc(expected.length); // Prevent length leaking too if (!timingSafeEqual(expected, safeBuffer)) { /* reject */ } 3. SSRF is harder than you think (IPv6 mapped addresses) We allow users to "replay" webhooks to arbitrary URLs. Classic SSRF vulnerability. The obvious fix is blocking private IPs like 127.0.0.1 and 10.0.0.0/8. The gotcha: ::ffff:127.0.0.1 bypasses naive regex blocklists. It's an IPv4-mapped IPv6 address that resolves to localhost. We had to: Resolve DNS (A + AAAA records) before making the request Normalize IPv6 addresses to IPv4 where applicable Check against a comprehensive blocklist including cloud metadata (169.254.169.254) 4. In-memory rate limiters can OOM your server Most rate limiters use a simple Map. A botnet scanning with 100k random IPs will grow that map indefinitely until you crash. The fix: Sliding Window + LRU eviction. We cap at 1,000 entries. When full, the oldest IP is evicted before inserting a new one. Memory stays bounded regardless of attack volume. 5. Searching large datasets without loading them into memory Users can replay webhooks from days ago. Naively loading thousands of events into memory to find one by ID will OOM your container. The fix: Iterative pagination with early exit: ```javascript while (true) { const { items } = await dataset.getData({ limit: 1000, offset, desc: true }); if (items.length === 0) break; const found = items.find((i) => i.id === targetId); if (found) return found; offset += 1000; // Only fetch next chunk if not found } ``` This keeps memory constant regardless of dataset size. 6. Replay retry with exponential backoff (but only for the right errors) When replaying webhooks to a user's server, network blips happen. But blindly retrying every error is dangerous—you don't want to hammer a 404. The pattern: Distinguish transient from permanent errors: ```javascript const RETRYABLE = ["ECONNABORTED", "ECONNRESET", "ETIMEDOUT", "EAI_AGAIN"]; if (attempt >= 3 || !RETRYABLE.includes(error.code)) throw err; const delay = 1000 * Math.pow(2, attempt - 1); // 1s, 2s, 4s await sleep(delay); ``` 7. Header stripping for safe replay If you replay a production webhook to localhost, you probably don't want to forward the Authorization: Bearer prod_secret_key header.
We maintain a blocklist of sensitive headers that get stripped automatically: javascript const SENSITIVE = ["authorization", "cookie", "set-cookie", "x-api-key"]; const safeHeaders = Object.fromEntries( Object.entries(original).filter(([k]) => !SENSITIVE.includes(k.toLowerCase())) ); 8. Hot-reloading without losing state Platform-as-a-Service environments treat configs as immutable. But restarting just to rotate an API key drops all SSE connections. We implemented a polling loop that reads config every 5 seconds. The tricky part is reconciliation: If urlCount increases from 3→5: generate 2 new webhook IDs If urlCount decreases from 5→3: don't delete existing IDs (prevents data loss) Auth key changes take effect immediately without restart 9. Self-healing bootstrap for corrupted configs If a user manually edits the JSON config and breaks the syntax, the server shouldn't crash in a loop. The fix: On startup, we detect parse errors and auto-recover: javascript try { config = JSON.parse(await readFile("INPUT.json")); } catch { console.warn("Corrupt config detected. Restoring defaults..."); await rename("INPUT.json", "INPUT.json.bak"); await writeFile("INPUT.json", JSON.stringify(defaults)); config = defaults; } The app always starts, and the user gets a clear warning. TL;DR: The "easy" parts of building a real-time webhook service are actually full of edge cases—especially around proxies, security, and memory management. Happy to discuss any of these patterns in detail. Source code (https://github.com/ar27111994/webhook-debugger-logger) if you want to see the implementations. <!-- SC_ON --> submitted by /u/ar27111994 (https://www.reddit.com/user/ar27111994)
[link] (https://github.com/ar27111994/webhook-debugger-logger) [comments] (https://www.reddit.com/r/programming/comments/1qdof8e/the_surprisingly_tricky_parts_of_building_a/)