code-server: Auth redirect does not work under cloudflare universal SSL

  • code-server version: 1.0.0
  • OS Version: Debian 9, using docker

Steps to Reproduce

  1. Setup Cloudflare with universal SSL ( Which basically turns on their proxy service )
  2. That’s it. The auth redirect somehow does not work! Doesn’t matter what password I use, it just redirects to the same login page, with no useful indication in either client or server console

If I either drop down Cloudflare SSL and use plain HTTP, or disable auth and directly run with --no-auth option, both work just fine…

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 22 (6 by maintainers)

Most upvoted comments

We use the same filenames in both the authed and unauthed bundle so your browser is caching them. This will be fixed soon!

Great! Was thinking about using .htpasswd as well, but I guess now I just need to wait a bit 😃

@Pitu Wow apparently that worked! Upon further testing, the only thing that’s mattered was Disable cache (while DevTools is open) option… But how does this make any sense tho? (scratching my head trying to figure out what went wrong…) All local cache was clear before any kind of testing, Cloudfare cache was bypassed (Development Mode), multiple browsers and devices have been tested…

@Pitu Thx! Though I have tried it out yet still not working Deployed Letsencrypt SSL on the server, direct connection works fine. With CloudFlare SSL set to Full (Strict), Universal SSL and Always use HTTPS, along with your nginx proxy config, still, no way to log in.

This is a wired one… Though the part that I did not copy were the ssl settings… which should not matter in theory? My current nginx config, just for reference

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # managed by Certbot
    server_name your.domain.com;
    location ~ /.well-known/acme-challenge {
        allow all;
        root /usr/share/nginx/html;
    }

    location / {
        add_header Access-Control-Allow-Origin *;
        try_files $uri @proxy;
    }
    location @proxy {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass http://localhost:8443;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_redirect off;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    if ($host = your.domain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name your.domain.com;
    return 404; # managed by Certbot


}


Thx! And I have confirmed (at least from my limited testing) Full SLL does not work, either. Drop their SSL and use self-signed one works, tho.

–allow-http has always been specified in the docker-compose command 😉 The service works fine with --no-auth option, after all.