Thank you. That worked!
M. Thanks for looking at this. I figured out the problem.
In my project XXX.Web.Core I left around the Microsoft.IdentityModel.xxxx packages. Those were replaced with some other packages, but it still allowed the project to build, making me think they were previously used versions of the package. Anyway, once i went through the solution, project by projects and compared the Packages I was able to find the problem. No lengthening of the SecurityToken was necessary.
Just a warning to all people performing upgrades: Carefully check the packages and versions for each project in the solution against the new downloaded version.
Thanks, Gerry
@m.aliozkaya Thank you so much for your response. I really appreciate it.
Making the JwtBearer.SecurityKey longer did change where the issue is occurring; I just arbitrarily added a random 12 character string; 11 characters repeated the previous behavior, and 12 characters allowed it to succeed to the next failure. Since that was the default token that the template was generated with, i'm guessing this will be a problem for others. Did the hash key size change?
Now when the loginService eventually calls the ZeroRefreshTokenService, it invokes the tryAuthWithRefreshToken(). Within that method it calls getRefreshToken() which fails, and causes the redirect to the internal pages to fail.
Any insight would be much appreciated, especially why I had to make any changes at all to the SecurityKey length.
Many thanks, Gerry
p.s. I went to my aspnetzero branch which contained the newly downloaded project and created a new database and ran the project. Login was still broken. I also noticed that much of the client authentication/JWT code was refactored over the last release. Any chance i'm hitting a framework issue and not a bad merge/upgrade?
I think it has to do with not having a UnitOfWork or not having the UnitOfWork restricted to a given tenancy. Any help here would be greatly appreciated.
Thanks!
