Hi,
I'm using .Net Core MVC template and I've updated my framework template from 9.01 to 11.4.1. It is working fine in stagging server and localhost, but, when deployed to the production server, it is raising an exception:
ERROR 2023-03-08 20:17:13,895 [78 ] uthentication.JwtBearer.JwtBearerHandler - Exception occurred while processing message.
System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
at Internal.Cryptography.UniversalCryptoDecryptor.GetPaddingLength(ReadOnlySpan1 block) at Internal.Cryptography.UniversalCryptoDecryptor.UncheckedTransformFinalBlock(ReadOnlySpan1 inputBuffer, Span1 outputBuffer) at Internal.Cryptography.UniversalCryptoDecryptor.UncheckedTransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) at Internal.Cryptography.UniversalCryptoTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) at System.Security.Cryptography.CryptoStream.ReadAsyncCore(Memory1 buffer, CancellationToken cancellationToken, Boolean useAsync)
at System.Security.Cryptography.CryptoStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at Abp.Runtime.Security.SimpleStringCipher.Decrypt(String cipherText, String passPhrase, Byte[] salt, Nullable`1 keySize, Byte[] initVectorBytes)
at ASL.iAPIS.Web.Startup.AuthConfigurer.SetToken(MessageReceivedContext context, Boolean allowAnonymous) in E:\Products\iAPISWeb\iapisprod7mar\head\iAPIS_11.4.1\src\ASL.iAPIS.Web.Mvc\Startup\AuthConfigurer.cs:line 245
at ASL.iAPIS.Web.Startup.AuthConfigurer.QueryStringTokenResolver(MessageReceivedContext context) in E:\Products\iAPISWeb\iapisprod7mar\head\iAPIS_11.4.1\src\ASL.iAPIS.Web.Mvc\Startup\AuthConfigurer.cs:line 214
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
I've searched, but, with no success to find out what is wrong. I've compared both environments and haven't found any difference.
Do you have any idea what could be wrong?
Kind regards, Leonardo Willrich.
5 Answer(s)
-
0
Hi,
What happens when you try this on Chrome's incognito mode ? Maybe your old token is stored in the browser and can't be decrypted.
-
0
Hi Ismcagdas,
As it is hosted in production, the request should be coming from some customer computer. I don't know how to map what is the origin. It is an event from AuthConfigurer for SignalR apparently. Do you how if there is a way to identify the requester in this case?
Checking AbpAuditLogs for the last 24 hours, with ExecptionMessage not null, I can see a high number (100 more or less) of this message: "Refresh token is not valid!"
Can it be related?
-
0
Hi,
I think it is something like I explained before. When a SignalR connection is created, we encyrpt a key and send it to client, then client sends it back to server and we decrypt it. In this case, some clients have a value which is encyrpted with an old approach and we are trying to decrpty it with a new approach. In time, this should be all gone when users logout and login to the application.
Refresh token is not valid!
This is not related I guess.
-
0
Ok, maybe, the users are still using cached website pages/scripts and haven't reloaded with CTRL+F5.
-
0
Yes, this might be one of the reasons.
