kevinchalet.com Open in urlscan Pro
2606:50c0:8000::153  Public Scan

Form analysis
1 forms found in the DOM

GET //google.com/search

<form action="//google.com/search" method="get" accept-charset="UTF-8" class="search-form"><input type="search" name="q" class="search-form-input" placeholder="Search"><button type="submit" class="search-form-submit"></button><input type="hidden"
    name="sitesearch" value="https://kevinchalet.com"></form>

Text Content

Kévin Chalet's blog
Home Archives




KÉVIN CHALET


.NET-HOLIC AND OPENID-ADDICT MVP IN THE WILD.

France Follow me on Twitter
43 posts
36 tags




CONNECTING WINDOWS MEDIA CENTER TO TVHEADEND WITH HDHRPROXYIPTV: AN ALTERNATIVE
TO DVBLINK

2023-07-05
Development

After more than 13 years of continuous use, I'm saying goodbye to my traditional
Windows Media Center TV setup 😊

Like many (if not most) users, I've always been using Windows Media Center with
terrestrial tuners physically attached to my HTPCs:

 * A USB dual-tuner Sony PlayTV when I started playing with WMC back in 2008 (an
   excellent device that's still working just fine).
 * A PCI dual-tuner Hauppauge WinTV-NOVA-TD-500.
 * A PCIe dual-tuner AVerMedia AVerTV Duo Hybrid (the hardware is good but the
   driver is terrible and has been responsible for a lot of blue screens...)
 * A PCIe quad-tuner Hauppauge WinTV-quadHD – great hardware and great driver! –
   when I eventually got tired of the crashes caused by the AVerTV Duo Hybrid.

While this setup certainly lacked the flexibility of more elaborate options
based on network tuners (like the popular HDHomeRun) or virtualized tuners such
as the now defunct DVBLink, it was actually trivial to set up and exceptionally
stable, specially since replacing the old TV tuners by newer Hauppauge
WinTV-quadHD cards (these things are not only ultra-stable but they also offer
low-latency channel switching and have a fairly good reception).

So, why changing something that has been working so well? It all started with a
message posted by a user of the My Digital Life forum – acer-5100 – about using
Windows Media Center with H.265/HEVC channels.

As you probably already know, due to internal Windows Media Center/DirectShow
limitations, only MPEG1, MPEG2 and H.264 channels are supported and it's not
possible to watch or record H.265/HEVC channels, even if you install the
appropriate DirectShow codecs. Since WMC was abandoned by Microsoft many years
ago, it's extremely unlikely we'll ever see an update to make it compatible with
HEVC channels.

To work around this limitation, acer-5100 opted for a simple but clever setup
that consists in combining DVBLink (and its IPTV source plugin) with Tvheadend:
by simply configuring DVBLink to use transcoded streams provided by Tvheadend
rather than the original HEVC sources, Windows Media Center always gets a good
old MPEG2 or H.264 video stream it can decode without any issue. Simple and
clever.

Read more

Share Comments
 * dvblink
 * hdhomerun
 * hdhrproxytv
 * tv
 * tvheadend
 * windows media center


INTRODUCING SYSTEM INTEGRATION SUPPORT FOR THE OPENIDDICT CLIENT

2023-02-27
Development

Note: this blog post was updated to use the new record-based APIs introduced in
OpenIddict 4.5.

When I unveiled the new OpenIddict client stack a year ago, I mentioned that one
of the core design goals was to avoid coupling it to ASP.NET Core to eventually
allow using it basically everywhere. With the release of OpenIddict 4.1, I'm
making one additional step towards this goal by adding experimental support for
Windows and Linux applications.


WHY IS A DEDICATED SYSTEM INTEGRATION PACKAGE NECESSARY?

While the OpenIddict client can already be used as-is to implement
non-interactive flows like password or client credentials (thanks to its
dedicated APIs in OpenIddictClientService), interactive flows like the code,
hybrid or implicit flows are more complicated to implement, as they typically
require launching the system browser (or using some sort of web view) to
redirect the user to the authorization server and handling the authorization
callback, which is generally implemented using an embedded web server or by
registering a custom protocol URI scheme.

Leaving these critical parts as an exercise wouldn't offer a great experience.
To avoid that, the new OpenIddict.Client.SystemIntegration package takes care of
launching the user's preferred browser and handles the authorization responses
returned by the identity provider to the protocol URI scheme associated with the
application (or posted to the embedded web server), in a completely transparent
way.

Once configured, doing a complete code flow dance should be as easy as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


try
{
    // Ask OpenIddict to initiate the authentication
    // flow (typically, by starting the system browser).
    var result = await _service.ChallengeInteractivelyAsync(new()
    {
        ProviderName = provider
    });

    // Wait for the user to complete the authorization process.
    var response = await _service.AuthenticateInteractivelyAsync(new()
    {
        Nonce = result.Nonce
    });

    MessageBox.Show($"Welcome, {response.Principal.FindFirst(Claims.Name)!.Value}.",
        "Authentication successful", MessageBoxButton.OK, MessageBoxImage.Information);
}

catch (ProtocolException exception) when (exception.Error is Errors.AccessDenied)
{
    MessageBox.Show("The authorization was denied by the end user.",
        "Authorization denied", MessageBoxButtons.OK, MessageBoxIcon.Warning);
}


Read more

Share Comments
 * asp.net core
 * authentication
 * oauth
 * openid connect
 * openiddict
 * web providers


OPENIDDICT 4.0 GENERAL AVAILABILITY

2022-12-23
Development

Two years after OpenIddict's last release, I'm very pleased to announce that 4.0
is now generally available! 🎉


WHAT'S NEW?

While both the server and validation stacks include many internal improvements
(some of them were described in OpenIddict 4.0 preview1 is out), the most
visible change of this release is the addition of the new client stack and its
17 web providers that aim at offering an alternative to the aspnet-contrib
providers (additional services will be added in future versions of OpenIddict):

Provider nameApplePayPalAmazon CognitoPro Santé
ConnectDeezerRedditGitHubStackExchangeGoogleTraktKeycloakTwitterLinkedInWordPressMicrosoft
Accounts/Azure ADYahooMixcloud

If you're interested in learning more about the new OpenIddict client, don't
miss these blog posts:

 * Introducing the OpenIddict client
 * OpenIddict 4.0 preview1 is out
 * Getting started with the OpenIddict web providers

To see the OpenIddict client in action, you can give the OpenIddict samples a
try, as most of them have been updated to use it.


MIGRATION

While OpenIddict 4.0 comes with some breaking changes, the migration process
should be fairly easy. To help users with this process, an OpenIddict 4.0
migration guide was added to the documentation.

OpenIddict 4.0 is fully compatible with ASP.NET Core 2.1 (on .NET Framework),
ASP.NET Core 3.1, ASP.NET Core 6.0 and ASP.NET Core 7.0, so the migration can be
done without having to upgrade to the latest .NET runtime/ASP.NET Core version.


SUPPORT

With OpenIddict 4.0 being now generally available, the previous version,
OpenIddict 3.0, stops being supported and won't receive bug fixes or security
updates. It is recommended to migrate to OpenIddict 4.0 to continue receiving
bug and security fixes.


ACKNOWLEDGEMENTS

As always, a new major release is a great opportunity to thank all the sponsors
who have helped keep OpenIddict free for everyone. Every contribution counts –
of course! – but I'd like to dedicate this release to 3 sponsors in particular,
who have a special place in my heart:

 * Volosoft: it might sound surprising, but Volosoft is the first and only
   company that has spontaneously offered to sponsor the project while
   evaluating OpenIddict as a replacement for IdentityServer4 in their (very!)
   popular ABP Framework project. Without Volosoft's incredible support, it's
   very likely the project would no longer be as active as it today (or even
   free for everyone).

 * Dovydas Navickas: Dovydas is one of the very first OpenIddict sponsors. Even
   though he stopped using OpenIddict after a big career change some time ago,
   Dovydas decided to keep sponsoring the project! This level of support is
   truly amazing so thank you very much Dovydas!

 * Jasmin Savard: Jasmin doesn't use OpenIddict but decided to give away a
   significant part of the sponsorship he receives as one of the most important
   Orchard Core contributors to keep OpenIddict free for everyone else. No need
   to say this dedication leaves me absolutely speechless!

I hope you'll love OpenIddict 4.0 as much as I enjoyed working on it.

Merry Christmas everyone! 🎄 🎁

Share Comments
 * asp.net core
 * aspnet-contrib
 * authentication
 * jwt
 * oauth
 * openid connect
 * openiddict


GETTING STARTED WITH THE OPENIDDICT WEB PROVIDERS

2022-12-16
Development

Note: this blog post was updated to use the OpenIddict 4.7 packages.

Earlier this year, I unveiled the new web providers that will ship as part of
the OpenIddict 4.0 release.

To help users understand the differences between the existing aspnet-contrib
providers and the new OpenIddict-based providers, I also posted additional
information on the aspnet-contrib repository ; so if you're considering
replacing the aspnet-contrib providers by their equivalent in OpenIddict, don't
miss it.

Today, we're going to see how to easily get started by creating a minimal
application that uses the OpenIddict.Client.WebIntegration package.

At the time of writing, 16 providers – Apple, Cognito, Deezer, GitHub, Google,
Keycloak, LinkedIn, Microsoft, Mixcloud, PayPal, Reddit, StackExchange, Trakt,
Twitter, WordPress and Yahoo – are already available, but to keep things simple,
we'll focus our attention on a single one: GitHub.


CREATE A NEW ASP.NET CORE APPLICATION

For this step, we could use one of the Visual Studio templates, but since
there's a trend towards doing things the "minimalistic" way, we're only going to
add two files: a .csproj file containing the package references we'll need and a
Program.cs file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15


<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="7.0.10" />
    <PackageReference Include="OpenIddict.AspNetCore" Version="4.7.0" />
    <PackageReference Include="OpenIddict.EntityFrameworkCore" Version="4.7.0" />
  </ItemGroup>

</Project>


1
2
3
4
5
6
7
8
9
10
11
12


var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseUrls("https://localhost:44381/");

builder.Services.AddAuthentication();
builder.Services.AddAuthorization();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

await app.RunAsync();


If you run this application as-is, all you'll get is a 404 response as we didn't
register any HTTP handler. We'll get back to that in a few minutes.

Read more

Share Comments
 * asp.net core
 * aspnet-contrib
 * authentication
 * github
 * oauth
 * openid connect
 * openiddict
 * web providers


OPENIDDICT 4.0 PREVIEW1 IS OUT

2022-06-22
Development

Earlier today, the first OpenIddict 4.0 preview was pushed to NuGet.org 🎉

As always, all the changes can be found on GitHub but here's a recap of the most
interesting ones:


WHAT CHANGED?


OPENIDDICT NOW INCLUDES A CLIENT STACK

The introduction of a client stack in 4.0 is by far the most exciting change
(well, at least for me 😁).

If you missed my previous post, I'd suggest reading it first as it details the
motivation for creating it and the differences with existing offers like the
ASP.NET Core OpenID Connect or OAuth 2.0 handlers.


THE OPENIDDICT CLIENT WILL COME WITH A COMPANION PACKAGE TO SIMPLIFY WELL-KNOWN
WEB SERVICES INTEGRATIONS

I had mentioned in my previous blog post that I was interested in developing an
alternative to the aspnet-contrib providers that would be based on the new
OpenIddict client instead of the ASP.NET Core 2.0 base handler and would have
the following advantages:

 * Thanks to its dual-protocol nature, the OpenIddict client could enforce all
   the security checks introduced by OpenID Connect that a simple OAuth 2.0
   client implementation like the ASP.NET Core OAuth 2.0 base handler wouldn't
   support, which means we could easily support both OAuth 2.0 and OpenID
   Connect providers without sacrificing security.

 * By being natively compatible with ASP.NET Core (from 2.1 to 7.0) and
   OWIN/Katana 4.2, the providers built on top of the OpenIddict client could be
   used in both recent ASP.NET Core apps and legacy ASP.NET >= 4.6.1 apps,
   making them usable in many more applications than the aspnet-contrib
   providers, that always target the most recent ASP.NET Core version.

 * Unlike the OAuth 2.0 base handler developed by Microsoft, the OpenIddict
   client comes with a composable events model that could allow eliminating code
   that we needed to copy in the aspnet-contrib providers when overriding
   certain OAuthHandler methods.

The good news is that this idea materialized as a dedicated
OpenIddict.Client.WebIntegration package that depends on OpenIddict.Client and
includes the logic necessary to deal with all the non-standard aspects of each
supported provider. Unlike the aspnet-contrib providers,
OpenIddict.Client.WebIntegration relies on Roslyn Source Generators to
dynamically create all the plumbing code, which makes it much easier to
maintain. If you're interested in learning more about the technical details,
don't miss the PR that introduced it.

If you're already familiar with the aspnet-contrib providers, migrating to the
OpenIddict-based providers shouldn't be too complicated:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


services.AddOpenIddict()

    // Register the OpenIddict core components.
    .AddCore(options =>
    {
        // Configure OpenIddict to use the Entity Framework Core stores and models.
        // Note: call ReplaceDefaultEntities() to replace the default OpenIddict entities.
        options.UseEntityFrameworkCore()
               .UseDbContext<ApplicationDbContext>();
    })

    // Register the OpenIddict client components.
    .AddClient(options =>
    {
        // Enable the redirection endpoint needed to handle the callback stage.
        //
        // Note: to mitigate mix-up attacks, it's recommended to use a unique redirection endpoint
        // address per provider, unless all the registered providers support returning an "iss"
        // parameter containing their URL as part of authorization responses. For more information,
        // see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.4.
        options.SetRedirectionEndpointUris(
            "/signin-local",
            "/signin-github",
            "/signin-google",
            "/signin-reddit",
            "/signin-twitter");

        // Register the signing and encryption credentials used to protect
        // sensitive data like the state tokens produced by OpenIddict.
        options.AddDevelopmentEncryptionCertificate()
               .AddDevelopmentSigningCertificate();

        // Register the ASP.NET Core host and configure the ASP.NET Core-specific options.
        options.UseAspNetCore()
               .EnableStatusCodePagesIntegration()
               .EnableRedirectionEndpointPassthrough();

        // Register the Web providers integrations.
        options.UseWebProviders()
               .AddGitHub(new()
               {
                   ClientId = "[client identifier]",
                   ClientSecret = "[client secret]",
                   RedirectUri = new Uri("https://localhost:44381/signin-github", UriKind.Absolute)
               })
               .AddGoogle(new()
               {
                   ClientId = "[client identifier]",
                   ClientSecret = "[client secret]",
                   RedirectUri = new Uri("https://localhost:44381/signin-google", UriKind.Absolute),
                   Scopes = { Scopes.Profile }
               });
    });


Read more

Share Comments
 * asp.net core
 * aspnet-contrib
 * authentication
 * jwt
 * oauth
 * openid connect
 * openiddict

123…9Next &raquo;


RECENTS

 * Connecting Windows Media Center to Tvheadend with HDHRProxyIPTV: an
   alternative to DVBLink
   
   2023-07-05

 * Introducing system integration support for the OpenIddict client
   
   2023-02-27

 * OpenIddict 4.0 general availability
   
   2022-12-23

 * Getting started with the OpenIddict web providers
   
   2022-12-16

 * OpenIddict 4.0 preview1 is out
   
   2022-06-22


CATEGORIES

 * Development32
 * General1


TAGS

 * .net1
 * asp.net1
 * asp.net core30
 * asp.net core identity1
 * aspnet-contrib25
 * auth02
 * authentication36
 * azure1
 * azure ad1
 * cms1
 * component object model1
 * dvblink1
 * github1
 * hdhomerun1
 * hdhrproxytv1
 * jwt32
 * manifest1
 * oauth36
 * okta1
 * openid1
 * openid connect35
 * openiddict21
 * orchard1
 * orchardcore1
 * owin6
 * razor1
 * tls1
 * tv1
 * tvheadend1
 * uwp1
 * vulnerability2
 * web authentication broker1
 * web providers2
 * windows2
 * windows 101
 * windows media center2


ARCHIVES

 * July 20231
 * February 20231
 * December 20222
 * June 20221
 * February 20221
 * May 20211
 * December 20201
 * November 20201
 * October 20203
 * August 20201
 * July 20201
 * June 20201
 * March 20201
 * February 20201
 * April 20191
 * November 20181
 * October 20181
 * August 20181
 * July 20181
 * June 20182
 * February 20181
 * January 20181
 * October 20171
 * August 20172
 * May 20171
 * March 20171
 * January 20171
 * November 20161
 * August 20161
 * July 20169

© 2016 - 2023 Kévin Chalet
Proudly powered by Hexo with Ruipeng Zhang's Icarus theme and Madison Slater's
photos.