Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates for .NET8 Preview 7 #1401

Merged
merged 17 commits into from
Sep 15, 2023
Merged

Updates for .NET8 Preview 7 #1401

merged 17 commits into from
Sep 15, 2023

Conversation

leastprivilege
Copy link
Member

@leastprivilege leastprivilege commented Aug 30, 2023

...maybe we want to wait for preview 8. As expected the JWT handler has some regressions (e.g. "sub claim is missing").

leastprivilege and others added 8 commits August 30, 2023 13:03
This is needed because of changes in the token handler
The new version of wilson deserializes the claims differently.
This commit changes the DPoP's use of the jwk claim and adds
a test that we still handle complex subclaims (arrays for key_ops)
The new wilson version's limitation when reading a complex
Header and Payload value into a dictionary is that it requires
that you specify the concrete Dictionary type rather than the
IDictionary interface.

Thus, we can go back to the original way of reading the jwk,
and then serializing it into json to pass to the JsonWebKey
ctor, we just need to use Dictionary instead of IDictionary
when retrieving the header.
The test in question creates a proof token, and now creates the
jwk parameters as a Dictionary<string, object> rather than an
anonymous type which is then serialized by System.Text.Json.

In the new wilson version, claims can be passed as dictionaries, but
not as anonymous types.
@brockallen
Copy link
Member

Also, @josephdecock, take note of the warnings about obsolete APIs that are being used. We should find the new/replacement APIs and use those now instead.

@brockallen brockallen added this to the 7.0.0 milestone Sep 8, 2023
JWTs are already representing the jwk claim as a JsonElement,
and we don't need additional conversions
AddAsync is only needed for value generators that need async database
access (e.g., HiLoValueGenerator), and we don't use those generators
Code analysis points out that that throws if the header is already set.
In this situation, multiple www-authenticate headers would be nonsense,
so we explicitly throw if that happens.
@josephdecock josephdecock marked this pull request as ready for review September 12, 2023 15:52
@josephdecock
Copy link
Member

All the warnings are now resolved as well.

  • There was a warning about DbSet.Add vs DbSet.AddAsync. We should not change to AddAsync here.

    This method is async only to allow special value generators, such as the one used by 'Microsoft.EntityFrameworkCore.Metadata.SqlServerValueGenerationStrategy.SequenceHiLo', to access the database asynchronously. For all other cases the non async method should be used.

  • There was a warning about setting http headers by calling Add on the dictionary of headers. This throws if you've already set the header. In our case, we were setting the www-authenticate header this way. It actually would be an error if the www-authenticate header was set twice, so I check for that explicitly now.

@brockallen brockallen merged commit f69718e into main Sep 15, 2023
5 checks passed
@brockallen brockallen deleted the dom/update-to-net8-preview7 branch September 15, 2023 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants