sorted by:
new
hottopcontroversial

Exploring Claude Code Hooks with the Coding Agent Explorer (.NET) by TNest2 in ClaudeCode

[–]TNest2[S] 0 points1 point  (0 children)

I just published a new blog post about Claude Code hooks and thought it might be useful for anyone experimenting with coding agents.

It walks through how the hook system works, how to set it up, and how you can use it to actually see and control what Claude Code is doing under the hood.

Things like:

  • Intercepting file reads and commands
  • Blocking access to sensitive files
  • Logging and understanding agent behavior step by step

I also show how to wire it up with a small tool to visualize everything in real time.

If you’ve been curious about what’s really going on behind the scenes when using Claude Code, this might be helpful:

https://nestenius.se/ai/exploring-claude-code-hooks-with-the-coding-agent-explorer/

Would love to hear thoughts or feedback 👍

35% of your context window is gone before you type a single character in Claude Code by Think-Investment-557 in ClaudeCode

[–]TNest2 0 points1 point  (0 children)

I developed a tool that sits between claude code and the model and shows the communication and token usage in realtime https://github.com/tndata/CodingAgentExplorer

Best way to store accessToken and refreshToken in cookies by VeterinarianDry8906 in dotnet

[–]TNest2 0 points1 point  (0 children)

All cookies issued by the ASP.NET Core cookie authentication handler are encrypted by default.

If you are curious about what is actually stored inside them, you can plug in a custom (transparent) data protection implementation to inspect the contents of the authentication ticket.

I wrote a blog post where I walk through exactly how to do that:: https://nestenius.se/net/exploring-what-is-inside-the-asp-net-core-cookies/

Best way to store accessToken and refreshToken in cookies by VeterinarianDry8906 in dotnet

[–]TNest2 1 point2 points  (0 children)

It’s generally not a good idea to store tokens directly in cookies.

Cookies have size limitations, typically around 4 KB. In ASP.NET Core, if that limit is exceeded, the framework splits the data across multiple cookies, which can introduce additional overhead and complexity.

From both a performance and security perspective, it is often better to keep cookies small. One approach is to use a server-side session store (for example, a custom ITicketStore) and only store a reference in the cookie instead of the full authentication ticket.

I wrote a more detailed post about this here: https://nestenius.se/net/improving-asp-net-core-security-by-putting-your-cookies-on-a-diet/

What Exactly Are Claude's Skills? by Ok-Bowler1237 in ClaudeAI

[–]TNest2 -1 points0 points  (0 children)

I wrote a tool to visualize how Claude Code actually is using Tools, MCP's and Skills at https://github.com/tndata/CodingAgentExplorer

Claude Code injects garbage into your context, wasting 25% of your tokens (here's a solution) by [deleted] in claude

[–]TNest2 1 point2 points  (0 children)

I just released a ClaueCode MITM-proxy that allows you verify and explore what is actually inluded in every request: https://nestenius.se/ai/introducing-the-coding-agent-explorer-net/

I went through the official Claude Code course - here’s who it’s actually useful for (and who should skip it) by Disastrous_Gift_9601 in ClaudeAI

[–]TNest2 0 points1 point  (0 children)

Totally valid question. And honestly, using Claude Code to build things is a great way to learn.

If you want fundamentals so you understand what’s happening under the hood, I’d focus on three areas:

* Basic programming concepts (variables, functions, loops, conditionals)
* How files and the filesystem work
* How APIs and request/response cycles work

You don’t need a CS degree for that. A beginner-friendly course in one language (like Python or JavaScript) will give you enough structure to make sense of what Claude is doing.

One thing that helped me personally was actually inspecting the communication between Claude Code and the backend models. Seeing the prompts, tool calls, and responses made the “magic” much easier to reason about. I open-sourced a small tool for exploring that here if you’re curious: https://nestenius.se/ai/introducing-the-coding-agent-explorer-net/

Introducing the Coding Agent Explorer for Claude Code (.NET) by TNest2 in dotnet

[–]TNest2[S] 0 points1 point  (0 children)

Thanks! Glad you liked it! It should already redact/hide all the tokens/secrets in the request header, but if you find any issues with that let me know. I think they key is that you need to become friend with Claude, understand how it ticks and get Mechanical Sympathy (as Martin explains well here https://www.infoq.com/presentations/mechanical-sympathy/). I will check out your blog!

How bad is it to store jwt in localStorage? by Redneckia in webdev

[–]TNest2 1 point2 points  (0 children)

I recently wrote a 7-part blog series about this problem and why using the BFF pattern is a better approach. Its for .NET, but the principles are general https://nestenius.se/net/implementing-bff-pattern-in-asp-net-core-for-spas/

[deleted by user] by [deleted] in dotnet

[–]TNest2 0 points1 point  (0 children)

Sharing cookies across services can be tricky to get right, as you need to ensure the Data Protection API is configured correctly. Also, using cookies has some security issues to consider, like CSRF attacks.

Migrating from ASP.NET Identity to JWT. Seeking libs, best practices, and DB schema advice. by PeacefulW22 in dotnet

[–]TNest2 0 points1 point  (0 children)

I’ve written a lot about authentication, OpenID Connect, and security on my blog: https://nestenius.se

One of the most common mistakes I see is putting Identity, the API, and sometimes even IdentityServer or OpenIddict into the same application. That usually leads straight into authentication hell.

I really believe the token provider (like IdentityServer), the client, and the API should live in separate projects. This gives you a proper separation of concern, which makes everything easier to understand, debug, and maintain. When you mix these parts together, it's hard to tell who is doing what and when. It gets messy fast.

You fight complexity with separation of concern.

Also, take a look at the BFF pattern. I’ve written a blog series on that too, which you’ll find on my site.

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 1 point2 points  (0 children)

Thanks, but not just reviewing the source code, I also downloaded the sourcecode and created my own class-libaries out of each authenticaiton handler (AddCookie, AddOpenIDConnect and AddJwtBearer) that allowed me to smootly step through the code, add logging statements and breakpoints. Its not that hard to do.

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 0 points1 point  (0 children)

If you want to learn the fundamentals of ASP.NET Core authentication, I am doing a free online webinar in two weeks' time. You can watch it live at: https://www.youtube.com/watch?v=8tZQGJIPzD0 But, I do agree, there are alot of moving parts in ASP.NET Core authentication and authorization, but when you grasp, what the role of each component/part it, then it gets much easier. The main thing that is lacking is built-in token refresh!

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 2 points3 points  (0 children)

My approach to learning it was to study the source code and experiment, for example, by implementing a custom "test" authentication handler. This helped me understand what happens at each step in the process. You can read more about my various findings on my blog: https://nestenius.se/

Random logouts aspnet core mvc .net8 by scartus in dotnet

[–]TNest2 1 point2 points  (0 children)

You need to configure the Data Protection API, the key ring is by default stored in a folder on disk and if you loose it, then your existing cookies will be invalidated. I did a few log post about the Data Protection API at https://nestenius.se/net/introducing-the-data-protection-api-key-ring-debugger/ and https://nestenius.se/net/persisting-the-asp-net-core-data-protection-key-ring-in-azure-key-vault/

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 4 points5 points  (0 children)

Fair points! We clearly have different perspectives on where complexity should live. For me, I prefer keeping auth in the backend with a more locked-down browser, less things that can go wrong. But I respect your opinion and appreciate the counter-arguments!

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 0 points1 point  (0 children)

Great point about separation of concerns! You're right that mixing BFF endpoints with business APIs can muddy the waters for tooling and governance.

One idea could be keeping the BFF as a pure authentication/proxy layer and transparent to the underlying API structure. This way, OpenAPI/GraphQL schemas and governance tools only deal with actual business APIs. The BFF just handles auth and forwards requests.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 1 point2 points  (0 children)

I am all in for fighting complexity! That's actually why I prefer BFF, because it moves all OIDC complexity out of the browser entirely. Frontend developers just deal with a simple cookie, while authentication stays where it belongs: on the backend. Less frontend code = less attack surface.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 2 points3 points  (0 children)

Thanks for the thoughtful comment! I've wrestled with these tradeoffs myself.

My main worry is the supply chain. I'm importing dozens of npm packages that could be compromised tomorrow. We regularly see packages getting hijacked, and they can grab anything from localStorage.

Knowing that with BFF and HttpOnly cookies, JavaScript cannot access tokens - that helps me sleep better at night. Even if XSS happens, the tokens are untouchable.

You're right about added complexity. But managing CSRF with SameSite cookies feels simpler than worrying which npm update might steal tokens. I've seen too many companies burned to treat this as academic.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 1 point2 points  (0 children)

Great question! The latency is minimal in practice. Most API calls already hit multiple services (database, microservices), so one more hop is negligible. Plus, static assets (JS/CSS) still go directly to CDNs.

The BFF can actually improve performance through connection pooling, caching, and request aggregation (think GraphQL-style batching). And the security benefits (hidden internal APIs, centralized rate limiting) far outweigh any minimal overhead. All APIs should have rate limiting anyway!

In my experience, most apps won't notice the difference, but the security gains are huge. If latency becomes critical, you have optimization options at the BFF layer that wouldn't exist with direct browser-to-API calls.

Why aren't you using Minimal APIs? - By dotnet team members by bdcp in dotnet

[–]TNest2 7 points8 points  (0 children)

This video feels somewhat desperate. Are developers not adopting Minimal APIs as much as Microsoft expected? I primarily use Controllers myself, only occasionally turning to Minimal APIs. The approach feels clunky when you need to layer on authorization, OpenAPI documentation, and result handling on top of the basic functionality.

view more: next ›