Activities of "ipservant"

Thanks, we have adjusted it in that way and it is working fine. For the future we might add Stripe's customer Billing portal, too (where customers can set up new cards or cancel the subscription).

Hi,

Thanks for explaining, I think we will make some custom adjustments in the files you mentioned. I also think we will need to update to Stripe's current API as it supports VAT calculation now (and generally Stripe isn't very "good" at downwards compatibility...).

Just for point 1) it looks to me that if a customer once chose to go for a single payment, he will not be able to switch to subscription later (the button is not shown). Is that correct or did we maybe break something during a Zero update migration..? If it is correct, then we might disable single payments generally and go for subscriptions only (giving the customer the possibility to quit monthly).

Hi,

No worries :-) We use Postgres (like described here https://aspnetboilerplate.com/Pages/Documents/EF-Core-PostgreSql-Integration) and the collation property in the table properties says "German_Germany.1252". The DB was created with VS and the "update-database" command.

Did we apply anything wrong..?

Yes, my bad, sorry - of course I meant that it changes to https://default.coolapp.mydomain.com. It looks like already the common browsers are converting the request to lowercase for the domain part and not exen NGINX.

If I change the TenancyName from Default to default in the database, then I'm able to log in from the subdomain (but Zero creates an additional "Default" tenant on next start).

Is it even possible to identify tenants with case sensitive TenancyNames realiably by a subdomain? Or should TenancyNames generally be set lowercase on tenant creation?

Hi,

Sorry for the delay, we finally had the chance to investigate this further now. invalid_headers had been already set, the remaining issues were/are the following:

1. Firefox can throw CORS errors due to invalid SSL certificates -> problem solved
2. Accessing "https://Default.coolapp.mydomain.com" does not work because it canges to "https://Default.coolapp.mydomain.com" and thus redirects to host

Is this lowercasing an nginx issue or coming from the app?

Thanks again!

Hi,

thanks for the quick reply, unfortunately I can't find that file or GetClientIpAddress by global search in the whole project (Angular / .net core, separate projects). Can you give me a hint where to look at?

Yes, we have done that for the frontend already under the same IP, and there is currently no need to have the API redirect to https automatically as all the appsettings/appconfigs point towards https directly.

Thanks guys for the support, I think we're fine here to close the request :-)

Cool, we found the same approach yesterday and it seems to work fine so far. These are now our host and ng configs for the NGINX proxies, maybe they will be useful as referencs for others, too. Do you mind cross-checking them once more in regards of system availability and safety? Thanks!

upstream zero_hosts {
    server 10.0.0.3:9901;
    #more servers for load balancing/redundancy later
}

server {
    listen 443 ssl http2;
    server_name _;
    underscores_in_headers on;
    ignore_invalid_headers off;

    # your ssl files.
    ssl_certificate   /etc/nginx/conf.d/ip-servant.com_bundle.crt;
    ssl_certificate_key  /etc/nginx/conf.d/ip-servant.com.key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-real-IP $remote_addr;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # your backend service(docker container name).
        proxy_pass http://zero_hosts;
    }
}

upstream zero_ngs {
    server 10.0.0.3:9902;
}

server {
    listen 80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name _;
    underscores_in_headers on;

    # your ssl files.
    ssl_certificate   /etc/nginx/conf.d/ip-servant.com_bundle.crt;
    ssl_certificate_key  /etc/nginx/conf.d/ip-servant.com.key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-real-IP $remote_addr;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # your backend service(docker container name).
        proxy_pass http://zero_ngs;
    }
}

Thanks, I followed that and set up a separate NGINX docker instance for frontend and host each. I had to add proxy_http_version 1.1; to make SignalR/Websocket work, but there is still an issue left that I can't switch language or tenant at the very first login page (it just reloads with the previous language and always as host, no tenant). Am I missing any config on NGINX? This happens only if I route host throgh NGINX and regardless of http or https.

Here is my NGINX config for host:

    upstream myapp1 {
        server 10.0.0.3:9901;
    }

server {
    listen 443 ssl http2;

    server_name _;

    ssl on;

    # your ssl files.
    ssl_certificate   /etc/nginx/conf.d/xxx.crt;
    ssl_certificate_key  /etc/nginx/conf.d/xxx.key;

    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    underscores_in_headers on;

    location / {
proxy_http_version      1.1;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-real-IP $remote_addr;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # your backend service(docker container name).
        proxy_pass http://myapp1;
    }
}

...and the part that came with the docker image:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

Again, thanks for your advice!

Hi zony,

thank you very much for the information! We followed your suggestion and have set up a reverse proxy environment based on an OPNsense firewall with NGINX plugin acting as reverse proxy with SSL offloading, but having issues with occasional 504 errors now.

The setup looks like this: WAN (public IP, port 4443/https) - OPNsense with NGINX - ZeroHost (private IP, port 8081/http on Docker container)

At first glance, the ZeroHost seems to be reachable fine, the certificate is also accepted by the browsers and Swagger UI is working. But then, after a couple of minutes and/or calls to the API (I didn't find a 100% reliable way to reproduce yet) the page is giving 504 errors by the NGINX proxy. If I open a second browser window (in incognito mode to make sure it has no "past"), then the page is reacting fine again until, after more or less the same time as described above, I'm getting 504s again. The ZeroHost was always replying fine directly on the Docker port though (tested with curl on the OPNsense's CLI), so I don't believe in "real" timeout of the app, but a proxy issue.

This is what NGINX logs say about it: *777 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 5.171.xx.78, server: subdomain.our-domain.com, request: "GET /api/services/app/Objekte/GetDistinctAkteForObjekte HTTP/2.0", upstream: "http://172.20.xx.2:8081/api/services/app/Objekte/GetDistinctAkteForObjekte", host: "subdomain.our-domain.com:4443", referrer: "https://subdomain.our-domain.com/"

Before NGINX I was trying the same setup with pfSense and HAProxy, which showed the exact same behavior, with the following log of HAProxy, where the sH-- flag is stating something like "server-side timeout" and "proxy was waiting for complete, valid response HEADERS from the server":

[2020-10-11T11:16:14.857080] Incoming log entry; line='<134>Oct 11 13:16:14 haproxy[78394]: 116.202.xxx:54896 [11/Oct/2020:13:15:14.839] frontend-host~ backend-host_ipvANY/172.20.x.2 0/0/1/-1/60018 504 194 - - sH-- 1/1/0/0/0 0/0 "GET /swagger/index.html HTTP/1.1"\x0a'

What are we missing?! Followed really basic howtos on the setups using the GUI tools of pfSense/HAproxy and OPNsense/NGINX to create the proxy configs and played around with various settings, but with no luck so far. Do you have a working NGINX template for SSL offloading as reference? I'm not posting mine (yet) as it is quite long (and this post already is..), but I can of course do that if necessary.

Any help is appreciated!