Skip to main content

I am developing a system flow. After having an previous error (Procedure or function 'prc_rapport_queue_flow_export_decision_get_record' expects parameter '@send_mail', which was not supplied.) I keep getting the following error when I try to restart the system flow once more with Postman:

 

>ERR] TSFMessagesMiddleware: An unhandled exception occurred while processing the request. (fffadd8a)
System.Security.Cryptography.CryptographicException: The key {2bd012cc-a47d-4c33-8209-a3c0fa41639c} was not found in the key ring. 

 

2022-11-02T12:29:53.7410002+01:00 8000008c-0000-f000-b63f-84710c7967bb bERR] TSFMessagesMiddleware: An unhandled exception occurred while processing the request. (fffadd8a)
System.Security.Cryptography.CryptographicException: The key {2bd012cc-a47d-4c33-8209-a3c0fa41639c} was not found in the key ring. For more information go to http://aka.ms/dataprotectionwarning
   at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte(] protectedData, Boolean allowOperationsOnRevokedKeys, UnprotectStatus& status)
   at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.Unprotect(Bytec] protectedData)
   at Microsoft.AspNetCore.DataProtection.DataProtectionCommonExtensions.Unprotect(IDataProtector protector, String protectedData)
   at Indicium.Authorization.ApplicationClaimCache.MetaSourceApplicationClaimer.tryGetUseLogSessionID(HttpContext httpContext, Int32& useLogSessionID) in C:\azp\agent\_work\1\s\src\Indicium\Authorization\ApplicationClaimCache.cs:line 185
   at Indicium.Authorization.ApplicationClaimCache.MetaSourceApplicationClaimer.ClaimApplication(TSFRequestContext requestContext, HttpContext httpContext, Int32 guiApplID, Boolean allowClaimExtension) in C:\azp\agent\_work\1\s\src\Indicium\Authorization\ApplicationClaimCache.cs:line 124
   at Indicium.Authorization.ApplicationClaimCache.ClaimApplication(IApplicationLoader applicationLoader, TSFRequestContext requestContext, Int32 guiApplID) in C:\azp\agent\_work\1\s\src\Indicium\Authorization\ApplicationClaimCache.cs:line 52
   at Indicium.OData.ApiModelCache.GetModel(String guiApplAliasOrID, TSFRequestContext requestContext, ISession userSession, Boolean refreshModel) in C:\azp\agent\_work\1\s\src\Indicium\OData\ApiModelCache.cs:line 94
   at Indicium.OData.MetaSourceApiModelCache.GetApiModel(String metaSourceAliasOrID, String guiApplAliasOrID, TSFRequestContext requestContext, ISession userSession, Boolean refreshModel) in C:\azp\agent\_work\1\s\src\Indicium\OData\MetaSourceApiModelCache.cs:line 67
   at Indicium.Middleware.Telemetry.ServerTimings.ServerTimingsBuilder.CaptureiT](String key, Func`1 action) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\Telemetry\ServerTimings\ServerTimingsBuilder.cs:line 41
   at Indicium.OData.ODataRouteValueTransformer.TransformAsync(HttpContext httpContext, RouteValueDictionary values) in C:\azp\agent\_work\1\s\src\Indicium\OData\ODataRouteValueTransformer.cs:line 114
   at Microsoft.AspNetCore.Mvc.Routing.DynamicControllerEndpointMatcherPolicy.ApplyAsync(HttpContext httpContext, CandidateSet candidates)
   at Microsoft.AspNetCore.Routing.Matching.DfaMatcher.SelectEndpointWithPoliciesAsync(HttpContext httpContext, IEndpointSelectorPolicyx] policies, CandidateSet candidateSet)
   at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.<Invoke>g__AwaitMatch|8_1(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task matchTask)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context)
   at Indicium.Middleware.Security.AuthenticationHeadersMiddleware.InvokeAsync(HttpContext context) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\Authentication\AuthenticationHeadersMiddleware.cs:line 47
   at Indicium.Middleware.Security.SecurityHeadersMiddleware.InvokeAsync(HttpContext context, ContentSecurityPolicyBuilder cspBuilder) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\Security\SecurityHeadersMiddleware.cs:line 54
   at Indicium.Middleware.Messages.TSFMessagesMiddleware.Invoke(HttpContext context, IRootApplicationLoader rootApplicationLoader, TSFRequestContext requestContext) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\Messages\TSFMessageMiddleware.cs:line 44
   at Indicium.Middleware.Telemetry.ServerTimings.ServerTimingsMiddleware.InvokeAsync(HttpContext context, ServerTimingsBuilder serverTimingsBuilder) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\Telemetry\ServerTimings\ServerTimingsMiddleware.cs:line 42
   at Indicium.Middleware.ExceptionHandlingMiddleware.Invoke(HttpContext context, IRootApplicationLoader rootApplicationLoader, TSFRequestContext requestContext) in C:\azp\agent\_work\1\s\src\Indicium\Middleware\ExceptionHandlingMiddleware.cs:line 35
 

 

I tried to recycle the application pool of Indicium but it does not help. 

Ok, ter info voor iedereen na mij: blijkbaar zitten de geplaatste cookies in de weg. Als ik de cookie weghaal in Postman dan werkt het weer. Dit heb ik ook al eens gemerkt bij de universal gui.

 

Kan iemand mij uitleggen waraom dit is en of dit ook anders kan?

 

Sorry, in English: removing the cookies did the trick. Why is this, can this be done in a diferent way?

 

Postman and Insomnia are very annoying with caching, for postman there is an option to turn this off but this is separate plugin which I have not been able to test yet. If possible I always test in the windows gui and later go to postman but since not all actions are available in the windows gui this is not always an option. 
In insomnia you can clear the cookies. But since I ran into this problem too often I Always make a new request since things like login credentials are also cached want to be 100% certain caching is not spoiling the party . 
 

 

In the defense of Postman and Insomnia, they are supposed to work this way, this is how a browser would do it as well.

In this specific case, there was an issue in Indicium which has been resolved in version 2022.2.15.x and above. Indicium was not supposed to throw 500 Internal Server Errors when receiving an outdated, encrypted cookie. Normally, this would just result in a warning that can safely be ignored, while Indicium issues a new cookie and continues working properly. So that was our fault, but the problem has already been fixed.

Everything below this point is off topic to the original question and is specifically aimed towards Erwin’s reply:

It can be experienced as annoying that Insomnia and Postman save cookies when testing changes against an SF meta source. Unlike IAM, the SF has no mechanism of informing Indicium of model changes. At the same time, it is not an option to constantly refresh the model when dealing with an Sf meta source. So the choice that we have made is that Indicium will only refresh the model when a new user session is calling the application. Since this requires you to constantly clear your cookies, we have also added a separate endpoint which can be called to force a model refresh:

POST
/sf/appl/refresh_model

Where appl is the alias or ID of the runtime configuration in the SF. Note that this is typically unnecessary for /iam/appl because those model changes should be picked up automatically.

I hope this explains a few things.

Terms & ConditionsCookie settings