warpgate: Returns 500 after clicking the sso button

My chrome version is 105.0.5195.102 After I clicked the sso button, I will get a error in the web console.

GET https://192.168.1.2:8888/@warpgate/api/sso/providers/custom/start?next=%2F 500
Ve.fetchApi	@	runtime.js:32
request	@	runtime.js:62
startSsoRaw	@	DefaultApi.js:258
startSso	@	DefaultApi.js:269
B	@	Login.svelte:119
ae	@	Login.svelte:208
a	@	Login.svelte:217

The runtime.js:32 is

let response = await (this.configuration.fetchApi || fetch)(fetchParams.url, fetchParams.init);

The http response is:

provider discovery error: Request failed

The log of the docker is:

warpgate_1  | Caused by:
warpgate_1  |     mapping values are not allowed in this context at line 22 column 38 in data/warpgate.yaml
warpgate_1  | 08.09.2022 17:01:33  INFO warpgate::commands::run: Warpgate version=0.5.1
warpgate_1  | 08.09.2022 17:01:33  INFO warpgate::config: Using config: "/data/warpgate.yaml" (users: 1, targets: 1, roles: 1)
warpgate_1  | 08.09.2022 17:01:33  INFO warpgate_protocol_ssh::server: Listening address=0.0.0.0:2222
warpgate_1  | 08.09.2022 17:01:33  INFO warpgate_protocol_http: Listening address=0.0.0.0:8888

There is no log about 500.

I use this docker-compose:

version: '3.1'
services:
  warpgate:
    image: ghcr.io/warp-tech/warpgate:v0.5.1
    ports:
      - "8888:8888"
      - "2222:2222"
    volumes:
      - ./etc/warpgate.yaml:/data/warpgate.yaml
      - ./var/data:/data
    restart: unless-stopped

and the config:

targets:
  - name: Web admin
    allow_roles:
      - "warpgate:admin"
    web_admin: {}
users:
  - username: admin
    credentials:
      - type: password
        hash: "${hash}"
    roles:
      - "warpgate:admin"
roles:
  - name: "warpgate:admin"
external_host: 192.168.1.2:8888
sso_providers:
  - name: custom
    label: SSO
    provider:
      type: custom
      client_id: ${client_id}
      client_secret: ${client_secret}:
      issuer_url: https://example.com
      scopes: ["email"]
  - name: google
    label: Google login
    provider:
      type: google
      client_id: 1234
      client_secret: ABC
recordings:
  enable: true
  path: /data/recordings
database_url: "sqlite:/data/db"
ssh:
  enable: true
  listen: "0.0.0.0:2222"
  keys: /data/ssh-keys
  host_key_verification: prompt
http:
  enable: true
  listen: "0.0.0.0:8888"
  certificate: /data/tls.certificate.pem
  key: /data/tls.key.pem
mysql:
  enable: false
  listen: "0.0.0.0:8888"
  certificate: /data/tls.certificate.pem
  key: /data/tls.key.pem
log:
  retention: 7days
  send_to: ~

Thanks!

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (6 by maintainers)

Commits related to this issue

include ca-certificates in docker image - #311 — committed to warp-tech/warpgate by Eugeny 2 years ago

Most upvoted comments

For what it’s worth, I also encountered the same issue where an OIDC service (Keycloak) with a completely trusted and legitimate TLS certificate was used. All browsers I tried (Chromium & FF), connected to this OIDC provider without any warnings and presented the lock with a “Connection is secure” message.

Similarly to https://github.com/warp-tech/warpgate/issues/311#issuecomment-1241086416 , I had the same output on the debug log. What fixed it for me, was dropping the container’s debian base in favor of fedora:

Dockerfile.builder:

FROM registry.fedoraproject.org/fedora:36

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --profile minimal --default-toolchain nightly -y && \
    source "$HOME/.cargo/env" && \
    cargo --version; \
    rustc --version; \
    dnf update -yq; \
    dnf install -yq nodejs java-17-openjdk-headless gcc openssl-devel perl; \
    dnf clean all; \
    npm install -g yarn; \
    cargo install just

Dockerfile:

FROM my.gitlab.instance/warpgate/builder:latest AS build

COPY . /opt/warpgate

RUN cd /opt/warpgate \
    && source "$HOME/.cargo/env" \
    && just yarn \
    && just openapi \
    && just yarn build \
    && cargo build --release

FROM registry.fedoraproject.org/fedora:36

COPY --from=build /opt/warpgate/target/release/warpgate /usr/local/bin/warpgate

VOLUME /data

ENV DOCKER 1

ENTRYPOINT ["warpgate", "--config", "/data/warpgate.yaml"]
CMD ["run"]

With this setup, everything else unchanged, SSO works to the very same OIDC provider. I did not bother to debug it further, I just wrote it up on debian being old and probably having some kind of incompatibility with TLS v1.3.

dt-zero on Sep 10, 2022