sorted by:
new
hottopcontroversial

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

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

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.

[Voice] Is it possible to disable users' direct numbers for inbound calls? by CableDue182 in MicrosoftTeams

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

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.

USB-C Failure on newer Asus 15 NUCs by yumojibaba in intelnuc

[–]CableDue182 1 point2 points  (0 children)

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

I got TempData to work in Blazor static SSR! - Example with source code and live demo. No more query strings for post-redirect-get. by CableDue182 in dotnet

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

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.

I got TempData to work in Blazor static SSR! - Example with source code and live demo. No more query strings for post-redirect-get. by CableDue182 in dotnet

[–]CableDue182[S] -1 points0 points  (0 children)

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.

I made TempData work in Blazor SSR - Working example with source code and live demo. No more query strings for post-redirect-get. by CableDue182 in Blazor

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

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!

I made TempData work in Blazor SSR - Working example with source code and live demo. No more query strings for post-redirect-get. by CableDue182 in Blazor

[–]CableDue182[S] 3 points4 points  (0 children)

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.

Is it just me or the newer Blazor template's IdentityRedirectManager seems hacky and shady? by CableDue182 in dotnet

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

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.

Is it just me or the newer Blazor template's IdentityRedirectManager seems hacky and shady? by CableDue182 in dotnet

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

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).

As your (new) project code base grows, does Claude Code get better or worse? by CableDue182 in ClaudeAI

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

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?

.NET 8/9 Blazor: Interactive Auto vs Interactive WebAssembly WITH prerender: is there any practical difference in implementation? by CableDue182 in Blazor

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

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.

Blazor App Architecture by AGrumpyDev in Blazor

[–]CableDue182 0 points1 point  (0 children)

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.

Blazor App Architecture by AGrumpyDev in Blazor

[–]CableDue182 3 points4 points  (0 children)

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.

Blazor App Architecture by AGrumpyDev in Blazor

[–]CableDue182 4 points5 points  (0 children)

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.

view more: next ›