-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Updating to .NET 8 Preview 1 breaks AuthorizationEndpoint query on AddGoogle #47054
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
Comments
What did the resulting url look like? It sounds like the options callback is being invoked twice for the same instance which would be bad. There was a bug in lazy options caching like that recently. |
@Tratcher The URL is: |
@Tratcher do you think this is a bug we've introduced that we need to address? |
@mkArtakMSFT yes, this needs to be investigated. |
To learn more about what this message means, what to expect next, and how this issue will be handled you can read our Triage Process document. |
The last line of BuildChallengeUrl() function causes duplicate parameters: |
Found the regression: afb6ec4#diff-dbfbf20eedf9c001d9d7848400c42e852216354b81f651f5bc82dbf42632475cR63 (thanks @PowerSaka) To enable PKCE in 8.0 the Google auth handler was changed to call which calls
This results in a query param list that contains the original parameters from AuthorizationEndpoint. Once google adds it's extra properties to the list it calls this again:
pulling the original parameters from the AuthorizationEndpoint again, causing duplication. Workaround:
.AddGoogle(o =>
{
o.ClientId = builder.Configuration["Google:ClientId"];
o.ClientSecret = builder.Configuration["Google:ClientSecret"];
- o.AuthorizationEndpoint += "?prompt=select_account"; // <-- Broken in .NET 8
+ o.Events = new OAuthEvents()
+ {
+ OnRedirectToAuthorizationEndpoint = c =>
+ {
+ c.RedirectUri += "&prompt=consent";
+ c.Response.Redirect(c.RedirectUri);
+ return Task.CompletedTask;
+ }
+ };
}); Possible fix: Since we know that
Note this is more complex than what other handlers support because they only support append, not per-challenge replacement of base parameters like scope.
Also, adding |
Thanks - I'll take a look at this some time in the next week to resolve that for our v8 release. |
Thanks for letting us know. Did you see any other provider that may be affected? If it's only VSO, then it's probably not a huge deal as it's almost a legacy thing: pretty much all APIs that use this provider can now be used with Azure AD directly (and Azure AD offers a much more OIDC-compliant implementation). |
I didn't see any other providers with issues, they all append rather than try to replace parameters. |
Looking at the docs, I'm not sure if we really need to do anything in our VisualStudioOnline provider. It seems that the only value recognised for I can't see a use case for someone genuinely needing to set it themselves and getting the duplication issue, unless I'm misunderstanding something about how the original issue applies in our case. |
@martincostello if someone added any query parameter to AuthorizationEndpoint it would get duplicated by the current code because of the pattern used to allow replacing an existing parameter. If nobody ever adds to AuthorizationEndpoint then you might never notice. |
Ah right, I see. Thanks - I'll take another look tomorrow. |
Update the process to include summary comment link in the description of the issue. This is important as I have noticed some issues have a long comment list and it's hard to discover the summary comment. Here is an example where I've noticed this: #47054
* Update HelpWantedProcess.md Update the process to include summary comment link in the description of the issue. This is important as I have noticed some issues have a long comment list and it's hard to discover the summary comment. Here is an example where I've noticed this: #47054 * Update docs/HelpWantedProcess.md Co-authored-by: Mackinnon Buck <[email protected]> * Update docs/HelpWantedProcess.md Co-authored-by: Mackinnon Buck <[email protected]> * Update docs/HelpWantedProcess.md Co-authored-by: Stephen Halter <[email protected]> * Update docs/HelpWantedProcess.md --------- Co-authored-by: Mackinnon Buck <[email protected]> Co-authored-by: Stephen Halter <[email protected]>
Any update on this? |
Should this be closed after the merged fixes ? |
Is anybody contributing to this story, if not I would like to contribute. |
I'd hold off @imparikshith. We might stop shipping the Microsoft.AspnetCore.Authentication.Google package altogether. See #61817 for more details. Instead, I'd recommend using the official official Google.Apis.Auth.AspNetCore3 NuGet package from Google which has a lot more functionality. You can find documentation for it at https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth#web-applications-asp.net-core-3. It mentions "ASP.NET Core 3", but it works with .NET 6.0+ as noted on their GitHub README at https://github.com/googleapis/google-api-dotnet-client. |
Uh oh!
There was an error while loading. Please reload this page.
The following web application correctly shows a Google sign in page when it is built with
net7.0
and version7.0.3
ofMicrosoft.AspNetCore.Authentication.Google
. Note that aprompt
query parameter is added to the authorization endpoint to force an account selection dialog to appear, rather than automatically signing in with the current Google account.In
net8.0
(Preview 1), the same app shows an error page on accounts.google.com:This is a breaking change, but I couldn't find it on the Breaking Changes in .NET 8 page. It might be enough of an edge case that it doesn't matter, but I thought I'd raise an issue just in case.
WebApplication1.csproj
Program.cs
dotnet --version
Summary Comment : #47054 (comment)
The text was updated successfully, but these errors were encountered: