Skip to content
This repository was archived by the owner on Dec 13, 2018. It is now read-only.

[Regression] SaveTokens + GetTokenAsync does not work for JwtBearer #1809

Closed
Tratcher opened this issue Jul 10, 2018 · 10 comments
Closed

[Regression] SaveTokens + GetTokenAsync does not work for JwtBearer #1809

Tratcher opened this issue Jul 10, 2018 · 10 comments
Assignees
Labels
Milestone

Comments

@Tratcher
Copy link
Member

Tratcher commented Jul 10, 2018

2.1 patch request for #1765, #1767

+This is a regression from 2.0.
+We've seen 3 customers hit this
+It's difficult for them to diagnose

-The workaround is trivial (read the value directly from the auth header). SaveTokens was only added to JwtBearer for consistency with the other providers.

@muratg
Copy link
Contributor

muratg commented Jul 10, 2018

cc @Eilon

@Eilon
Copy link
Member

Eilon commented Jul 10, 2018

Please add the necessary stuff to the shiproom OneNote.

@Tratcher
Copy link
Member Author

Where's the current OneNote?

@Eilon
Copy link
Member

Eilon commented Jul 11, 2018

I'll sent you the link.

@HaoK
Copy link
Member

HaoK commented Jul 11, 2018

Tests need to be added for this before taking it as a patch imo, the fix that was merged contained no tests...

@profet23
Copy link

I'd argue that since this is a regression and not a new feature, the priority should be on publishing a fix. GetTokenAsync is commonly referenced in documentation having to do with jwt authentication. This regression leads to a bug that is very hard to track down. The fix is simple and obvious.
Other libraries like: https://github.com/IdentityServer/IdentityServer4.AccessTokenValidation rely on this feature to be working.

The current state is that it was working in 2.0.x, the user updates their dependencies to 2.1.x and things stop working. Since the fix already exists in 2.2.x the dependent code will once again start working when that is released.

@HaoK
Copy link
Member

HaoK commented Jul 11, 2018

Adding tests for the fix doesn't affect when the it will be available.

This is more of an engineering concern rather than anything else, there's still no test coverage for something which already has been regressed once.

@profet23
Copy link

profet23 commented Jul 11, 2018

My concern is that the test issue #1768 has been open since May 23. I'm all for having the tests added, but I don't think it should be a blocking issue for 2.1.3. Making it a blocker for 2.2 is another story.

@Eilon Eilon added patch-approved SHP: Approved Shiproom has approved the issue and removed SHP: Approval pending Shiproom approval is required for the issue patch-proposed labels Jul 12, 2018
@Eilon
Copy link
Member

Eilon commented Jul 12, 2018

Patch is approved for 2.1.3. Please check in ASAP.

@Tratcher
Copy link
Member Author

@HaoK do you have bandwidth for this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants