I’m having problems installing the direct-payment app locally. Web is running without problems on local IIS.
Docker images are setup like suggested in Shared dependencies (litium.com). Dnsresolver dns is changed to 192.168.65.7 as I’m running latest Docker (4.19.0).
Payment app Docker image is setup by this:
direct-payment:
image: registry.litium.cloud/apps/direct-payment:1.3.0
dns:
- 192.168.65.2
restart: unless-stopped
ports:
- “10010:80”
- “10011:443”
environment:
# Enable HTTPS binding
- ASPNETCORE_URLS=https://+;http://+
- ASPNETCORE_HTTPS_PORT=10011
# Configuration for HTTPS inside the container, exported dotnet dev-certs with corresponding password
- ASPNETCORE_Kestrel__Certificates__Default__Password=xxx
- ASPNETCORE_Kestrel__Certificates__Default__Path=/https/localhost.pfx
# Folder for the configuraiton, this is volume-mapped
- CONFIG_PATH=/app_config
# Folder where logfiles should be placed, this is volume-mapped
- APP_LOG_PATH=/logs
# Don’t validate certificates
- AppConfiguration__ValidateCertificate=false
# Url to this app
- AppMetadata__AppUrl=https://direct-payment.localtest.me:10011
# Url to the litium installation
- LitiumApi__ApiUrl=https://softubelitium8.localtest.me
volumes:
- ./data/direct-payment/config:/app_config
- ./data/direct-payment/data:/app_data
- ./data/direct-payment/logs:/logs
- ./data/direct-payment/DataProtection-Keys:/root/.aspnet/DataProtection-Keys
- ./data/https:/https:ro
When running https://direct-payment.localtest.me:10011 as a logged in backoffice user with all permissions I get “The app could not be installed” message in backoffice and errors in the logs.
Payment app Docker image log says:
2023-05-09 11:25:18.6550 [App:01] [5f9e913c2206d1880406ce52c9280874] [ERROR] [.NET ThreadPool Worker] Microsoft.AspNetCore.Server.Kestrel - Connection id “0HMQGG05LFTC4”, Request id “0HMQGG05LFTC4:00000002”: An unhandled exception was thrown by the application. System.InvalidOperationException: IDX20803: Unable to obtain configuration from: ‘System.String’.
—> System.IO.IOException: IDX20804: Unable to retrieve document from: ‘System.String’.
—> System.Net.Http.HttpRequestException: Resource temporarily unavailable (softubelitium8.localtest.me:443)
2023-05-09 13:25:18.6684 [App:01] [5f9e913c2206d1880406ce52c9280874] [ERROR] Litium.Web.Administration.WebApi.Settings.Controllers.AppManagementController - Could fetch app metadata ‘https://direct-payment.localtest.me:10011/api/litium-app/metadata’. System.ArgumentException: Was not able to fetch app metadata from https://direct-payment.localtest.me:10011/api/litium-app/metadata
at Litium.Application.AppManagement.AppManagementServiceImpl.GetMetadataAsync(String url)
at Litium.Web.Administration.WebApi.Settings.Controllers.AppManagementController.InstallGet(String url)
Thanks, I guess that might work if you’re running the Litium website on localhost:5001 but I’m not.
LitiumApi__ApiUrl should, if I understand correctly, point to the url of the website. That seems to work fine since I’m redirected from the app to backoffice of my website when going to the url in AppMetadata__AppUrl.
The problem seems to be that the app doesn’t serve the metadata because of an error that’s seen in the app log.
That is a important point. Making sure that the app version works with your Litium version is important because neither Litium nor the app will tell you this in the error messages.
I’ve tried 1. Removed/commented out the DNS-entry completely, didn’t make any difference.
Can’t do 2. since my solution is running in local IIS.
I’ve done the reinstall/install steps so many times now, trying different things, I can’t even count them. No progress.
I get that that there are dependencies between versions. I’m trying to install the latest version of the Direct Payment app, 1.3.0 and I haven’t found anywhere what Litium version it works with. But I assume that since that was released in October 2022 and the versions of Litium I’ve tried install it on, standard Litium Accelerator 8.8 and our own solution based on 8.9, are both released in 2023, that they would work together.
Would be great with some input from the Litium people here. What inside the Direct Payment app triggers these errors to be thrown? @patric.forsgard@utku@anusha.ganegoda or anyone else? Looks to be something with Authentication but it’s not clear what.
2023-05-10 07:05:22.5132 [App:01] [55fcb3fd3f570894582149e53de0e008] [ERROR] [.NET ThreadPool Worker] Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler - Exception occurred while processing message. System.InvalidOperationException: IDX20803: Unable to obtain configuration from: ‘System.String’.
—> System.IO.IOException: IDX20807: Unable to retrieve document from: ‘System.String’. HttpResponseMessage: ‘System.Net.Http.HttpResponseMessage’, HttpResponseMessage.Content: ‘System.String’.
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel)
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
2023-05-10 07:05:22.5271 [App:01] [55fcb3fd3f570894582149e53de0e008] [ERROR] [.NET ThreadPool Worker] Microsoft.AspNetCore.Server.Kestrel - Connection id “0HMQH4JLQF9HL”, Request id “0HMQH4JLQF9HL:00000002”: An unhandled exception was thrown by the application. System.InvalidOperationException: IDX20803: Unable to obtain configuration from: ‘System.String’.
—> System.IO.IOException: IDX20807: Unable to retrieve document from: ‘System.String’. HttpResponseMessage: ‘System.Net.Http.HttpResponseMessage’, HttpResponseMessage.Content: ‘System.String’.
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel)
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
at Microsoft.AspNetCore.Authentication.AuthenticationHandler1.AuthenticateAsync() at Microsoft.AspNetCore.Authentication.AuthenticationService.AuthenticateAsync(HttpContext context, String scheme) at Microsoft.AspNetCore.Authorization.Policy.PolicyEvaluator.AuthenticateAsync(AuthorizationPolicy policy, HttpContext context) at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication1 application)
I have starting to get the same errors , and it doesnt matte if its direct pay/shipment or klarna… all logs basicaly the same thing… All have that strange Unable to obtain configuration from: ‘System.String’ message…
Change all 192.168.65.2 to 192.168.65.254 in that case. This works if your nslookup returns 192.168.65.254 for your host.docker internal. Otherwise use the ip that nslookup returns for your host.docker.internal
Ok, that seems to work. I notice that my elasticsearch also has dns: 192.168.65.2 but that seems to be working fine. Not sure if I need to change that as well and recreate the Docker container for that?
I needed to make the same change for ElasticSearch as well. It threw an exception when trying to rebuild the indices offline. Complaining about some Synonym key. But works as intended after the dns change.
As I wrote before, change all 198.168.65.2 to 192.168.65.254 and recreate the containers. Elastic search works probably since there is no call to Litium from elasticsearch.
