Open sathoril opened 5 years ago
Could you please check dev branch - https://github.com/skoruba/IdentityServer4.Admin/tree/dev?files=1 - there is prepared working version with docker. Give me please feedback :-) Thanks
Hey!
Thanks for the reply, I've already tried to run the application using that branch, mas I got the same error, here is a screenshot:
Is it that branch really working?
@bravecobra - any idea with this issue?
Just to update the issue, now I'm having this error page:
But, when I try to make the same request, from inside the container, it works.
I will test it at the weekend. 😊
STS works correctly, but I can not run MSSQL Server, so I need explore more details around docker in general. I have prepared a few changes regarding to db providers, wich will be possible to change the provider from appsettings.json. Does SqlServer work for you? Thanks
I think we have a case here of misunderstanding how docker and docker-compose works on a network level, together with the working of xip.io DNS resolving. Docker-compose basically starts up a mini virtual network.
networks:
identity-host:
driver: bridge
Each container can be considered as a tiny machine with its own IP address inside that network. If you want those little machine to work together you can refer to them by the name in the docker -compose. Look at the connection string of the database for instance. The connection string has the server db
which matches the name of the docker container running SQL server. Note how each machine has a container name specified, for instance
container_name: skoruba-identityserver4-admin
Now, what does "localhost" mean from the perspective of a container? Well, as they can be considered as a little machine, then to each machine, localhost resolves to itself, not the localhost of your host machine (on which you run docker).
Further, any address of xip.io resolves to localhost
, thus depending on where you run that command, the machine responding will be the machine you run the command on. In our case here, the API and Admin UI, run on different "machines", thus while http://127.0.0.1.xip.io:9000
resolves perfectly on Admin UI, it will not find http://127.0.0.1.xip.io:5000
, because API is not running on the "machine" of the Admin UI. If you want to resolve from one docker image to another, you need to refer to them with their docker name.
Each container may expose a port to the outside network and make it accessible to the "localhost" of your host machine. If you then call http://127.0.0.1.xip.io:5000
and http://127.0.0.1.xip.io:9000
on your host machine, each will resolve the correct machine, which is something that will not work if you try to resolve these on the individual containers themselves, since their localhost is their own "localhost", not the "localhost" of the host.
Unfortunately, OAuth requires a fqdn (fully qualified domain name) for the issuer. That means we cannot use the container names (as they are not fqdn) hence the usage of xip.io instead of the docker name resolving.
If you ran the seeding of the database, based on localhost instead of 127.0.0.1.xip.io
, then that configuration will not work inside a docker-compose env as the resolving will be incorrect when called from the docker host.
So, basically this is likely a case of incorrect configuration of both the seeding and the docker-compose file.
To confirm, could you try out the example of the dev branch?
But keep in mind that you need create the migrations before building and running as the migrations as not part of the source code, you need to generate that yourself. Start from a fresh database and use thedocker-compose.yml
as provided in the branch. There are a lot of env variables configured in each container which are ALL required to have the whole thing work correctly.
That all being said, how would you get rid of that xip.io configuration?
extra_hosts
option of docker-compose. We choose the xip.io configuration together with proper env variables as it would not require extra network configuration outside docker and thus just work out of the box for development purposes. This configuration is not meant to be used in production. Then again, you would not use docker-compose in a production environment anyway.
Thanks for your explanation, maybe what do you think about my use case, I've used your configuration of docker-compose (from dev branch), but I always get following error:
An unhandled exception occurred while processing the request. ExtendedSocketException: Name or service not known System.Net.Dns.InternalGetHostByName(string hostName)
SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 35 - An internal exception was caught)
I cannot figure out, how to connect to sql server. I have the ef migrations in my project as well.
Any idea? :-) Thanks
Do you have a sql server running on your host machine as well? In the docker-compose.yml
file the sql server is exposed on the host machine on port 1433. That might conflict with an existing sql server. You could choose a different port by changing that port and expose it differently like this:
db:
image: "mcr.microsoft.com/mssql/server"
ports:
- 1434:1433
Now you should be able to connect to the sql server instance with SSMS on localhost:1434 on your host machine, even though it's running inside a docker image. This is a security issue of course. What you want to do is to not expose the port to the host machine but only to the other services running in the same mini-network like this:
db:
image: "mcr.microsoft.com/mssql/server"
ports:
- 1433
but that would make debugging harder as you cannot connect to the database from your host machine. Try the following to see what docker-compose has running and how port are being forwarded
docker-compose ps
With the current configuration you should something like this:
λ docker-compose ps
Name Command State Ports
--------------------------------------------------------------------------------------------------------------------------
skoruba-identityserver4-admin dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32773->80/tcp,0.0.0.0:9000->80/tcp
skoruba-identityserver4-admin-api dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32771->80/tcp,0.0.0.0:5000->80/tcp
skoruba-identityserver4-db /opt/mssql/bin/permissions ... Up 0.0.0.0:1433->1433/tcp
skoruba-identityserver4-sts-identity dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32772->80/tcp,0.0.0.0:80->80/tcp
If you change the exposed port as suggested you should get something like this:
λ docker-compose ps
Name Command State Ports
--------------------------------------------------------------------------------------------------------------------------
skoruba-identityserver4-admin dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32773->80/tcp,0.0.0.0:9000->80/tcp
skoruba-identityserver4-admin-api dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32771->80/tcp,0.0.0.0:5000->80/tcp
skoruba-identityserver4-db /opt/mssql/bin/permissions ... Up 0.0.0.0:1434->1433/tcp
skoruba-identityserver4-sts-identity dotnet Skoruba.IdentitySer ... Up 0.0.0.0:32772->80/tcp,0.0.0.0:80->80/tcp
Notice how the port of sql server is now exposed differently to the outside world (being your host machine).
In SSMS you can then connect to that instance as localhost,1434
. (<- that a comma there to specify the port).
Also note that, since we don't specify the sql server version of the docker image, we use the latest sql server, currently being developer edition of 15.0 on Ubuntu.
If all that fails, it's likely to be a firewall issue.
@skoruba btw, if you want, I might do a live stream on twitch demonstrating the docker-compose setup as well a kubernetes configuration. Hit me up if you want to part of that stream.
@bravecobra Thanks for your tips, I will test it and report back the result. For sure, I want to watch your stream about these topics. Please let me know. 😊👍🏼
I am getting stil same error:
Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 35 - An internal exception was caught)
I did these steps:
1) Clone dev branch
2) Generate migrations
3) Change port 1433 to another, because I already have SQL Server
4) Exec command docker-compose up
5) I am able to show web site on http://127.0.0.1.xip.io
but without access to DB.
I use this on my computer with Windows 10 Enterprise. I am able to connect to SQL Server from SSMS.
I tried some proccess on another computer with same issue.
@bravecobra - Any idea?
So sql server is up and running as you are able to connect the changed port instance, right? Apart from the port no changes to the docker-compose file. What's the output of docker-compose ps
? Internally there should no firewalls.
@bravecobra Thanks for the explanation about how the docker-compose works, that helped a lot.
I tried at home using the dev branch configuration and everything works fine!! BUT, at work unfortunately I get the same error that I mentioned above (The "Connection Refused" error). And I did everything the same way.
Now, I'm thinking that is some configuration on the company's network or the computer that I use at work. I'm out of solutions now, does anyone have any idea what could it be?
Try adding network_mode: bridge
to each of the containers in docker-compose.yml
.
One thing I can think of is that docker-compose does not place the containers in the same "network", because another container already exists with the name name and it restarts that one instead of booting up a new one.
https://docs.docker.com/compose/compose-file/#network_mode
We use the default network here, maybe we need to be explicit about it.
I finally figure out, where it was problem in my case, the file docker-compose.override.yml
- loaded the connectionstrings from my secrets.
If I use - docker-compose -f docker-compose.yml up
- and change port of MSSQL from 1433 to another, it works. 👍
@bravecobra - Now I am considering how to use docker-compose.override
and docker-compose.vs.debug
in Visual Studio. Is it necessary to have these files in source control? (BTW: When do you plan - live stream about docker-compose and kubernetes ?) 😊
Thanks
It had to be something like that. No there is no absolute need to have them in source control, however they do provide a works-out-of-the-box experience without any negative impact. I'd leave them in. No fixed date planned yet for a stream. I suggest we talk about that somewhere else than in github issues.
For sure @bravecobra - can you mail/send me some contact? Thx
I've been using
networks:
idbackend:
name: idbackend
at the top of the docker-compose
then each container that needs db access has to be in that network (and possibly more for other container-container direct contact outside of this compose.
services
postgres:
# other setup for that container
networks:
- idbackend
identity:
# other setup for that container
networks:
- idbackend
no fqdn, and other docker containers outside that network have been able to ID4 interop. This is a private docker network, putting the skoruba stuff in a private network with the backend. The connection string used then (postgres example) uses Host=postgres
in the connection string. Then we add the container names to the hosts file as 127.0.0.1
and (http://identity:5004
for example) works.
we do have another network (docker external
) that all the other containers expecting to see the identity server are a part of.
This hasn't gone to production yet, but it is working locally in containers.
@ImaginaryDevelopment yep, that can work perfectly!
Hi guys,
I've been trying to get this working for a couple of days now and I'm out of ideas. I think the issue is the same as that experienced in this issue and I think it's a simple configuration issue. I'm setting this up on my mac with the plan to move it to a linux server once I've got it working.
I've replaced my FQD with example.com and I created a real DNS entry for that domain name resolving to public IP of my mac. Once deployed I'll move the FQD to the public IP of my VPS.
When running the application in this exact configuration without TLS/HTTPS set in the Caddyfile (and changing the URLs everywhere to http) the whole stack works beautifully.
After changing the Caddy config to use HTTPS and setting the URLs everwhere (including the db) to HTTPS the STS application, API and swagger seems to be working fine.
There is a problem with the admin app where it throws the following exception anytime it's accessed:
System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
System.Net.Http.HttpRequestException: Connection refused
---> System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
System.IO.IOException: IDX20804: Unable to retrieve document from: '[PII is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.
---> System.Net.Http.HttpRequestException: Connection refused
---> System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
--- End of inner exception stack trace ---
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.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: '[PII is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.
---> System.IO.IOException: IDX20804: Unable to retrieve document from: '[PII is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.
---> System.Net.Http.HttpRequestException: Connection refused
---> System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
--- End of inner exception stack trace ---
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.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Protocols.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleChallengeAsyncInternal(AuthenticationProperties properties)
at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleChallengeAsync(AuthenticationProperties properties)
at Microsoft.AspNetCore.Authentication.AuthenticationHandler`1.ChallengeAsync(AuthenticationProperties properties)
at Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, String scheme, AuthenticationProperties properties)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Localization.RequestLocalizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.CspMiddleware.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.MiddlewareBase.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.MiddlewareBase.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.MiddlewareBase.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.MiddlewareBase.Invoke(HttpContext context)
at NWebsec.AspNetCore.Middleware.Middleware.MiddlewareBase.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
My hunch is that there is missing or incorrect configuration in the skoruba.identityserver4.admin container that doesn't know how to work with the HTTPS configuration.
URLs:
Caddyfile:
# Redirect HTTP to HTTPS
http://auth.example.com:80 {
redir https://{host}{uri}
}
# STS TLS Proxy to internal docker container
https://auth.example.com:443 {
tls /data/certs/all-domains.crt /data/certs/all-domains.key
log /data/log/prod-access.log
errors /data/log/prod-error.log
proxy / http://skoruba-identityserver4-sts-identity:80 {
transparent
}
}
# API TLS Proxy to internal docker container
https://auth.example.com:5000 {
tls /data/certs/all-domains.crt /data/certs/all-domains.key
log /data/log/prod-access.log
errors /data/log/prod-error.log
proxy / http://skoruba-identityserver4-admin-api:80 {
transparent
}
}
# ADMIN TLS Proxy to internal docker container
https://auth.example.com:9000 {
tls /data/certs/all-domains.crt /data/certs/all-domains.key
log /data/log/prod-access.log
errors /data/log/prod-error.log
proxy / http://skoruba-identityserver4-admin:80 {
transparent
}
}
Docker compose file:
version: '3.4'
services:
skoruba.identityserver4.admin:
image: ${DOCKER_REGISTRY-}skoruba-identityserver4-admin
# ports:
# - 9000:80
build:
context: .
dockerfile: src/Skoruba.IdentityServer4.Admin/Dockerfile
container_name: skoruba-identityserver4-admin
environment:
- ASPNETCORE_ENVIRONMENT=Development
- "ConnectionStrings__ConfigurationDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__PersistedGrantDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__IdentityDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__AdminLogDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__AdminAuditLogDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "AdminConfiguration__IdentityAdminBaseUrl=https://auth.example.com:9000"
- "AdminConfiguration__IdentityAdminRedirectUri=https://auth.example.com:9000/signin-oidc"
- "AdminConfiguration__IdentityServerBaseUrl=https://auth.example.com"
- "AdminConfiguration__RequireHttpsMetadata=false"
- "IdentityServerData__Clients__0__ClientUri=https://auth.example.com:9000"
- "IdentityServerData__Clients__0__RedirectUris__0=https://auth.example.com:9000/signin-oidc"
- "IdentityServerData__Clients__0__FrontChannelLogoutUri=https://auth.example.com:9000/signin-oidc"
- "IdentityServerData__Clients__0__PostLogoutRedirectUris__0=https://auth.example.com:9000/signout-callback-oidc"
- "IdentityServerData__Clients__0__AllowedCorsOrigins__0=https://auth.example.com:9000"
- "IdentityServerData__Clients__1__RedirectUris__0=https://auth.example.com:5000/swagger/oauth2-redirect.html"
- "Serilog__WriteTo__1__Args__connectionString=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
command: dotnet Skoruba.IdentityServer4.Admin.dll /seed
depends_on:
- db
- skoruba.identityserver4.sts.identity
volumes:
- "./shared/serilog.json:/app/serilog.json"
- "./shared/identitydata.json:/app/identitydata.json"
- "./shared/identityserverdata.json:/app/identityserverdata.json"
- "./admin.appsettings.json:/app/appsettings.json"
skoruba.identityserver4.admin.api:
image: ${DOCKER_REGISTRY-}skoruba-identityserver4-admin-api
build:
context: .
dockerfile: src/Skoruba.IdentityServer4.Admin.Api/Dockerfile
# ports:
# - 5000:80
environment:
- "AdminApiConfiguration__RequireHttpsMetadata=false"
- "AdminApiConfiguration__ApiBaseUrl=https://auth.example.com:5000"
- "AdminApiConfiguration__IdentityServerBaseUrl=https://auth.example.com"
- "ConnectionStrings__ConfigurationDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__PersistedGrantDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__IdentityDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__AdminLogDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__AdminAuditLogDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
container_name: skoruba-identityserver4-admin-api
volumes:
- "./shared/serilog.json:/app/serilog.json"
- "./api.appsettings.json:/app/appsettings.json"
skoruba.identityserver4.sts.identity:
image: ${DOCKER_REGISTRY-}skoruba-identityserver4-sts-identity
# ports:
# - 80:80
build:
context: .
dockerfile: src/Skoruba.IdentityServer4.STS.Identity/Dockerfile
container_name: skoruba-identityserver4-sts-identity
environment:
- ASPNETCORE_ENVIRONMENT=Development
- "ConnectionStrings__ConfigurationDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__PersistedGrantDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "ConnectionStrings__IdentityDbConnection=Server=db;Port=5432;Database=IdentityServer4Admin;User Id=sa;Password=${DB_PASSWORD:-Password_123}"
- "AdminConfiguration__IdentityAdminBaseUrl=https://auth.example.com:9000"
depends_on:
- db
volumes:
- "./shared/serilog.json:/app/serilog.json"
- "./sts.appsettings.json:/app/appsettings.json"
- "./auth.example.com.pfx:/app/certificate.pfx"
# Don't know if this is needed..
networks:
default:
aliases:
- auth.example.com
db:
image: postgres:11
ports:
- 5432:5432
container_name: skoruba-identityserver4-db
environment:
POSTGRES_USER: sa
POSTGRES_PASSWORD: "${DB_PASSWORD:-Password_123}"
POSTGRES_DB: IdentityServer4Admin
volumes:
- ./postgres:/var/lib/postgresql/data
caddy:
image: abiosoft/caddy:latest
container_name: auth_proxy_caddy
ports:
- 80:80
- 443:443
- 5000:5000
- 9000:9000
volumes:
- ./Caddyfile:/etc/Caddyfile
- ./_letsencrypt/fullchain.pem:/data/certs/all-domains.crt
- ./_letsencrypt/privkey.pem:/data/certs/all-domains.key
- ./log:/data/log
restart: unless-stopped
volumes:
dbdata:
driver: local
networks:
default:
driver: bridge
App Settings & Certificates:
{
"ConnectionStrings": {
"ConfigurationDbConnection": "Server=localhost; User Id=postgres; Database=is4admin; Port=5432; Password=postgres; SSL Mode=Prefer; Trust Server Certificate=true",
"PersistedGrantDbConnection": "Server=localhost; User Id=postgres; Database=is4admin; Port=5432; Password=postgres; SSL Mode=Prefer; Trust Server Certificate=true",
"IdentityDbConnection": "Server=localhost; User Id=postgres; Database=is4admin; Port=5432; Password=postgres; SSL Mode=Prefer; Trust Server Certificate=true"
},
"DatabaseProviderConfiguration": {
"ProviderType": "PostgreSQL"
},
"CertificateConfiguration": {
"UseTemporarySigningKeyForDevelopment": false,
"CertificateStoreLocation": "LocalMachine",
"CertificateValidOnly": true,
"UseSigningCertificateThumbprint": false,
"SigningCertificateThumbprint": "",
"UseSigningCertificatePfxFile": true,
"SigningCertificatePfxFilePath": "/app/certificate.pfx",
"SigningCertificatePfxFilePassword": "my-cert-pass",
"UseValidationCertificatePfxFile": true,
"ValidationCertificatePfxFilePath": "/app/certificate.pfx",
"ValidationCertificatePfxFilePassword": "my-cert-pass",
"UseValidationCertificateThumbprint": false,
"ValidationCertificateThumbprint": ""
},
"RegisterConfiguration": {
"Enabled": true
},
"ExternalProvidersConfiguration": {
"UseGitHubProvider": false,
"GitHubClientId": "",
"GitHubClientSecret": ""
},
"SmtpConfiguration": {
"Host": "",
"Login": "",
"Password": ""
},
"SendgridConfiguration": {
"ApiKey": "",
"SourceEmail": "",
"SourceName": ""
},
"LoginConfiguration": {
"ResolutionPolicy": "Username"
},
"AdminConfiguration": {
"PageTitle": "Skoruba IdentityServer4",
"HomePageLogoUri": "/images/skoruba-icon.png",
"FaviconUri": "/favicon.ico",
"IdentityAdminBaseUrl": "http://localhost:9000",
"AdministrationRole": "SkorubaIdentityAdminAdministrator"
},
"CultureConfiguration": {
"Cultures": [],
"DefaultCulture": null
}
}
URLs in seeded data:
update "PersistedGrants" set "Data" = REPLACE("Data", 'http://127.0.0.1.xip.io', 'https://auth.example.com');
update "ClientCorsOrigins" set "Origin" = REPLACE("Origin", 'http://127.0.0.1.xip.io', 'https://auth.example.com');
update "ClientPostLogoutRedirectUris" SET "PostLogoutRedirectUri" = REPLACE("PostLogoutRedirectUri", 'http://127.0.0.1.xip.io', 'https://auth.example.com');
update "ClientRedirectUris" SET "RedirectUri" = REPLACE("RedirectUri", 'http://127.0.0.1.xip.io', 'https://auth.example.com');
Just to give you proper solution...I am using PostgreSQL...works as expected.
Someone has nicely described xip.io
concept of DNS.
Analogically, you have to declare all other dependant compose services using the same concept, especially database:
networks:
adminUiNetwork:
aliases:
- db.127.0.0.1.xip.io
Hello guys.
I've been trying to make this application to run inside multiple docker containers. I have already managed to do it but only with the Admin.Api project and the STS.Identity project, but I'm having problems with the Admin.UI project.
Everytime I try to access the url (http://localhost:9000) it shows this error:
I read that is possibly something related to the way I configure my network containers, but I tried everything I found on the internet and nothing worked.
I tried to instead using http://localhost:5000, I changed the url to connect to the following:
I dont know what should I do, do guys have any idea what this error is about.
Here is my Dockerfiles of each project and my docker-compose file:
Dockerfile - Admin.UI Project
Dockerfile.txt
Dockerfile - Admin.API Project
Dockerfile.txt
Dockerfile - STS.Identity Project
Dockerfile.txt
docker-compose file
docker-compose.txt