OrchardCMS
Docker container (OCC-350)
Using the same dockerfile than Orchard Core, which should work, fails to execute with an error 500.
2025-05-02 04:40:25.7948|ERROR|Microsoft.AspNetCore.Server.Kestrel|Connection id "0HNC96DQA79HL", Request id "0HNC96DQA79HL:00000001": An unhandled exception was thrown by the application.|System.InvalidOperationException: The antiforgery system has the configuration value AntiforgeryOptions.Cookie.SecurePolicy = Always, but the current request is not an SSL request.
Also:
error MSB3073: The command "corepack enable && corepack prepare [email protected]+sha1.aa4bc353b5f59fe1f1df5d802ce049ddf7f3c60e --activate && echo PNPM activated via corepack" exited with code 127.
Which should be fixed by removing node.js dependency from build.
Tested on main branch.
My bad I pushed directly to main branch the dockerfiles. If you want me to revert the commit let me know but these should be fine. We should probably not allow to push to main branch directly.
@sarahelsaig Do you know something in Lombiq Nuget packages that could enforce SSL on AntiforgeryToken. I've found nothing in this repository?
If anyone has time to try this and report if they at least can repro the issue that be appreciated. I will take a look at Lombiq repositories to find where this issue comes from. It doesn't come from OC bits as it works perfectly fine.
I tried setting the Cookie params and AntiforgeryToken to be SameAsSite but it did not work.
First, I made it work locally with a self signed certificate using a docker-compose.yml file and Microsoft documentation about how to run an aspnet core application under Docker with SSL.
Though, after trying deploying this docker container behind a reverse proxy that serves the SSL key for all underlying services I could not make this work.
The issue is that something in OCC enforces using SSL for the AntiforgeryToken. When using a reverse proxy you don't enforce using SSL in the docker container. You just serve it through HTTP and then the reverse proxy will take care of returning it to the client through its own SSL port. Everything in the private network can be done with HTTP. Also, normally this AntiforgeryToken should set itself to use SSL or not if we don't change its configuration.
So, my question is. Do you guys know which package does enforce SSL?
Here if we look at this enum: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.cookiesecurepolicy?view=aspnetcore-9.0
Normally the default should be "SameAsRequest" which has been changed to "Always" somewhere in OCC which is the issue.
So I found what triggers this.
ConfigureSecurityDefaultsWithStaticFiles in Program.cs
This here. Why is it necessary to be enforced if when it is set to "SameAsRequest" it will use proper configuration for the AntiforgeryToken?
Ok, I confirm that removing the ConfigureSecurityDefaultsWithStaticFiles in Program.cs fixed my issue. We should make this configurable so that by default we don't serve with HTTPS for docker containers behind a reverse proxy. That's all extension code from Lombiq repository which I can't really make changes without asking first.
@piedone
I will leave you guys decide what needs to be done here since it's related with Lombiq external dependency. Not sure if removing this line on my side will break other things but I'm going to do with it for now. 😄
For reference here is the Docker compose file I used to make the SSL working in the container:
services:
servicename:
image: imagename:latest // local image created with dockerfile
container_name: containername
build: .
ports:
- "80:80"
- "443:443"
environment:
ASPNETCORE_URLS: "https://+:443;http://+:80"
ASPNETCORE_ENVIRONMENT: "Development"
ASPNETCORE_Kestrel__Certificates__Default__Password: "pa55w0rd!"
ASPNETCORE_Kestrel__Certificates__Default__Path: "/https/OrchardCore.Commerce.Web.pfx"
volumes:
- ~/.aspnet/https:/https:ro
Which required that I create this OrchardCore.Commerce.Web.pfx file using this documentation:
https://learn.microsoft.com/en-us/aspnet/core/security/docker-https?view=aspnetcore-9.0
This works when using Docker locally for "Development" only. You can't use that local SSL key on production.
Having a default dev certificate is definitely better than turning off HTTPS. I think you can override those environment variables and specify a different the mounting in the docker run call. So in production you could point them to the host's certificate. Please check if that works, and add the above fix along with instructions in the docs.
Or would it be better to have two separate compose files for development and production? Then only include the ASPNETCORE_Kestrel__Certificates... and volumes in the one marked for development, so can't accidentally misconfigure it and still use the dev cert in production. What do you think?
Well, generally, when using Nginx or Traefik or Haproxy you create the certificate along with it because it is facing the internet. You will generally create the cert on the Proxy with Letsencrypt. Now, for me, the Proxy is on a different PC so I can't really mount a volume to it for prod.
Actually, you don't need to run the docker container with SSL because the proxy will handle serving the web app HTTP(local) to HTTPS(external). So, this is why I think adding a restriction to enforce SSL when using docker is not the best thing. I'd rather have a configuration to remove the AntiforgeryToken to enforce SSL and not have to even think about using a SSL key on dev or prod in my containers. That's how it works in general when I'm creating apps on my Truenas homelab ... it will not enforce using SSL in these containers unless it is specified through configuration.
We could have an environment var that would override simply this AntiforgeryToken SSL restriction to make it back using SameAsRequest. And to be honest I'm not even sure why we are changing this to "Always". If you don't want to serve the website through http then you redirect it to https?
On second thought, why are we concerned about the viability of OrchardCore.Commerce.Web on production anyway? It's meant to be a demo project for testing out OCC and reference when you set up your own web project. (I wouldn't expect anyone to check out the main OrchardCore git repo and try to deploy OrchardCore.Cms.Web into a real production server either. ) So the only thing that matters for its configuration is to work on a local machine out of the box.
I think the issue is that the default theme uses opiniated configurations that are set on a Lombiq repository for the default theme. We are simply missing a clean theme here and these Lombiq configurations could maybe be moved to a Lombiq theme. And we could also have a basic theme too which is missing badly.
If this ConfigureSecurityDefaultsWithStaticFiles could be moved in a Theme instead of being called directly on the Program.cs file then we could simply document its usage for those who want to enforce SSL.
The issue is not the fact that we are providing a Nuget package solution. We are just missing Themes/Recipes. And another issue is that we don't have a proper theme/recipe that actually display a running e-commerce website with common functionalities like a search and products with taxonomies and product filtering ...
But I think we digress into different topics. I think we can easily say that everyone that wants to run an e-commerce will start from this repository here and would expect that running it in Docker would work. Now, the Lombiq repository changes asp.net configurations to enforce SSL, I'm pretty sure we can find a way to make this configurable. Or we enable this only when using the default recipe which would make sense since it is a "testing theme".
And autosetup is creating this default site with that theme which is probably wrong too. But I'm guessing it is for CI testing.
OCC should have proper unit tests that creates tenants with proper recipes if that was the intent.