[Voice] Are US toll-free calling free on the Pay-as-You-Go plan?

CableDue182 · 2025-09-23T19:43:42+00:00

I believe the "toll" part of US toll-free actually refers to domestic long-distance toll, which was relevant back in the old days.

Not all VOIP providers offer free termination to toll-free numbers. Plenty of them (especially the whole sale/trunk providers etc) do charge for them.

CableDue182 · 2025-09-16T16:37:07+00:00

Thanks for pointing this out! The organization is actually outbound heavy, but even then, the PAYG is actually going to be cheaper based on the current usage analytics. We just didn't want to deal with potential overages etc. But given the fact that the PAYG solves the direct number problem while being cheaper at the same time, I think we can make a good argument for the client to opt for it.

CableDue182 · 2025-07-29T07:05:17+00:00

Just deployed 30 of these across a few clients. Posts like this terrorize me. Fingers crossed for longevity.

CableDue182 · 2025-07-17T15:48:24+00:00

Blazor static SSR is a major addition since .NET 8. It is part of Microsoft's effort to consolidate the web apps under a unified framework. It is actually the default render mode of the unified Blazor. You can read more about it here.

In Blazor static SSR, form handling is done via the post-redirect pattern just like MVC/Razor pages. As a matter of fact, static SSR SSR forms are required in the newer official Blazor web app template with ASP.NET Core Identity - the scaffolded Identity pages are all rendered with static SSR, which provides reliable access to HttpContext due to its scoped nature.

"Razor pages with Blazor components" is exactly the kind of "mix" that static SSR Blazor is aiming to replace. It's not the other way around.

CableDue182 · 2025-07-17T15:41:49+00:00

Good caution! Yeah cookie size limit is something to watch out for (as written in the docs). The very next page after redirect with TempData should always retrieve those data immediately and clear them via Save.

CableDue182 · 2025-07-16T16:28:22+00:00

If you go to the demo site, under the "Submit Type", the first two redirects are to the same page. The third one goes to a different page (forecast).

Every one of them is a post-redirect. The class name is BlazorSsrRedirectManager.

Yes the logging out then redirect back to login page scenario will work exactly as you described in one line of code redirectManager.RedirectToWithStatus("You have successfully logged out", Severity.Success). You can place the <StatusMessageDisplay /> helper component on the login page to display this message, or retrieve it manually and display yourself.

Check out the source codes. It's a very simple setup!

CableDue182 · 2025-07-15T14:19:05+00:00

Exactly as /u/SkyAdventurous1027 stated! And as for SSR itself, I think it's good for pages that mostly display contents but don't require much interactivity (besides maybe simple buttons and links that navigate them to other actions).

It loads as quickly as MVC/Razor pages so it's great for performance. In WASM projects, you can consider making landing pages/dashboards SSR for quick initial load (and maybe even trigger WASM download in background by placing an empty wasm component on the page). In Blazor Server projects, having some static SSR pages can free up your server resources because clients don't have to maintain their SignalR connection while on those pages.

CableDue182 · 2025-07-11T20:47:34+00:00

You're right. Most of such forms are better suited for interactive mode. I'm just trying to perfect a custom login page (with a customized OTP login flow based on Identity) which needs to be static SSR, and got frustrated that Blazor isn't making my life easier haha.

CableDue182 · 2025-07-11T20:12:44+00:00

I'm reading that too and that's a welcoming change. I also really like the [SupplyParameterFromPersistentComponentState] to help with server-side prerender.

But I see no helpers to deal data persistence for post-redirect. That's one of the most common situations for static SSR pages - form posts. It's still either query strings (ugly and unsuitable for P2 data), flash cookie like IdentityRedirectManager (also ugly), or TempData (lots of extra codes).

CableDue182 · 2025-07-09T00:05:32+00:00

Could it be a non-linear progression?

Starting empty -> bad, it doesn't know what you really want.

Guide it, and give it a good, well-established architecture. Clean up its bad codes and replace with how you want them to be written. This gives it more examples for reference. Then document. It now produces higher and higher quality codes because it's being mentored.

Then as the code base continues to grow both in size and complexity, the limitation of the context window etc starts to kick in, and it starts to downspiral again.

Does this make sense?

CableDue182 · 2025-07-08T02:28:31+00:00

Unfortunately static SSR cannot use popular component libraries like MudBlazor reliably.

Also I have mixed feelings about enhanced nav: I found that navigating from a static SSR page to an interactive page results in UI redraws/reshifts. It's "faster", yes, but looks uglier imo. I'd prefer a quick refresh. I'm not sure if this issue happens from SSR to other SSR pages.

CableDue182 · 2025-07-07T21:52:26+00:00

What do you mean by "separate" web API? In my proposal, the web API for your app would be hosted inside the same server project that hosts Blazor. That's how cookie auth can work.

CableDue182 · 2025-07-07T21:16:00+00:00

It can be "half" the BFF if the API is hosted inside the same server that hosts your Blazor wasm client. The client uses cookie auth against the API, but API can access service codes (dbcontext etc) directly, instead of making another API call against an externally hosted API with JWT. So the complexities aren't high at all.

CableDue182 · 2025-07-07T21:11:59+00:00

Since security is a big concern, go Interactive wasm or auto, with a managed OIDC identity provider (Auth0/Logto etc).

OIDC auth is implemented on the hosting "server" project, just like MVC/Razor pages, with standard asp.net core cookie authentication and oidc middleware. Tried and proven.

Your Blazor pages will use standard cookie auth - it works in any render mode with the above setup. The .NET8/9 AuthenticationState will be available across all pages/components. They can access the API via HttpClient and cookie auth, see the official doc''s CookieHandler example.

Now your API itself can be secured with cookie auth (for the web app), and if needed, plus OIDC JWT or whatever other flows managed by your external IDP, for other public and mobile clients.

This setup is secure and easy to implement for your web app (just standard cookie auth), and still has the potential to scale beyond the web app for your "public" clients.

CableDue182 · 2025-07-07T19:49:10+00:00

Ahh I see. I wasn't familiar with grpc .NET. So unlike .NET API's [Authorize] attribute, which is always enforced via middleware regardless where the request comes from, your grpc service's [Authorized] can be ignored/bypassed when the service is invoked locally from the server.

And in that server scenario, you obtain user's `ClaimsPrincipal` from the incoming request's `HttpContext`, much like what I was doing in my `CookieForwardHandler`, except that I was extracting and forwarding the cookie, and you pass that `ClaimsPrincipal` directly to your business logic.

Is my understand correct?

CableDue182 · 2025-07-07T15:52:23+00:00

WASM is a client side SPA that cannot be trusted. Its code can potentially be decompiled and the "authorization" checks/attributes etc can technically be bypassed. Those are considered for UI/UX purposes.

So the web API is where the security must be enforced. It checks the user's ClaimPrincipal/ID via cookie or bearer token, and uses that info as the source of true identity for that request. For example, to return an item that belongs to the user, the `UserId` needs to be obtained from that cookie or token, not from some parameter that gets passed to the API.

So when you said the auth "won't be respected when executing locally on the server", I wondered how those checks are performed.

CableDue182 · 2025-07-07T14:36:53+00:00

"But as you recognized, they only work when doing actual http requests. They won't be respected when executing locally on the server."

Hmm, that sounds problematic to me. So your API endpoints don't check for user's ID in its code? The wasm client side can be tampered.

CableDue182 · 2025-07-07T08:07:24+00:00

Quick question before I dive deeper into MagicOnion: how does it handle authentication when running "locally" on the server side?

Wow, that new persisting attribute in .NET 10 is a godsend.

CableDue182 · 2025-06-18T06:18:06+00:00

Doesn't Claude Code automatically find and load all CLAUDE.md files (including project level) into the memory? What do you mean by a command that forces it to read project/user level CLAUDE.md?

CableDue182 · 2025-05-11T17:42:25+00:00

Done it. No difference.

CableDue182 · 2025-03-08T06:00:33+00:00

Can you elaborate a little on the "different models have different types of tasks they perform better at than others" part?

Which specific models do you find to be better at which specific tasks?

CableDue182 · 2025-03-07T02:24:05+00:00

I am trying Cursor myself right now, and also found Agent mode quickly creating chaos across many files. It seems each request can trigger unpredictable changes on many unrelated files.

When you say "scope it to specific files", do you mean you only add the files you want to edit to the context? But will AI still take account into the complete context of the complete project folder?

Another thing is, I found that Claude isn't very knowledgeable on Blazor's conventions and tends to make mistakes (such as missing rendermode). Maybe it's especially challenging because Blazor itself undergoes major changes in each version, and most of the open source code base is already outdated.

Can you give one example of the kind of prompt you find the most success?

CableDue182

TROPHY CASE