https://www.gooddata.com/ logo
Join Slack
Powered by
Hi Team, I am seting up <GoodData.CN> CE 2.2.0 ver...
# gooddata-cn
d
Hi Team, I am seting up GoodData.CN CE 2.2.0 version to be under https and I am getting this error below. How can I configure 
use-forwarded-headers
as written in this article: https://community.gooddata.com/administration-61/unregistered-redirect-uri-using-built-in-oidc-identity-provider-412 also on CE edition. Many thanks, David.
r
Hi David, what are you using as a reverse proxy in front of GoodData.CN CE? Are you using Nginx as described in the article, or are you using a different software?
the article describes configuration of the Helm chart deployment in Kubernetes and the configuration is specific to Nginx Ingress Controller. If you're using GoodData.CN CE (standalone docker container), you rather need a docker-compose (or similar) setup that consists of gooddata-cn and some reverse proxy. Example setup using traefik is described here
d
Hi I am running GN.CN CE docker image on VM on GCP, in front of it I have GCP external http(s) load balancer … this should work the same as reverse proxy but I am not an expert on it, is there any experience on your side, can someone try to debug it with me?
r
let me check in our environment. We prefer running kubernetes version in cloud, but your setup (Community edition + LB) should work as well
Just successfully tested the following configuration: 1. VM e2-standard-4 with ContainerOS (image cos-101-17162-40-38), running container gooddata/gooddata-cn-ce:2.2.0 with the following env vars: LICENSE_AND_PRIVACY_POLICY_ACCEPTED=YES, GDCN_PUBLIC_URL=https://<<external-hostname>> 2. Regional L7 balancer with public IP that resolves to <<external-hostname>>, frontend ports 80,443; backend service points to instance group containing the VM above and to named port "http", default routing rule (all requests directed to backend service). SSL frontend has certificate attached. 3. Backend healthcheck I set on port 3000 and gave it longer interval (50s) 4. Unmanaged Instance group with port name mapping "http"=3000 I connected to https://<<external-hostname>> using browser and logged in without issues. I'm not sure what kind of LB are you using: global/regional? L4/L7? The global or regional choice should not make any difference. I can try with L4 (TCP) loal balancer.
L4 can't be used because it doesn't terminate TLS traffic.
It also works fine with global L7 LB.
d
seems I have same config with global L7 LB, would it be possible to jump on zoom call anytime when you will be free?
r
yes, no problem.
DM me the link
d
@Robert Moucha would it be ok to schedule tomorrow 9am?
r
9:30 am CET would be better. Is it ok?
d
yes
resolved: the issue was that in docker volume and dex internal db the organization was initiated with URL starting http:// and later change to https:// was not correctly applied > it has to be reinitiated with new volume
r
This procedure can be used to update value in dex database if you accidentally create organization with incorrect URL schema (e.g. with http:// instead of https://) and you need to change it later.
Untitled.txt
v
@Robert Moucha I am facing the same issue on 
gooddata/gooddata-cn-ce:2.3.0
deployed behind an alb ingress controller. I checked the sql database and this is what I come up with:
Copy code
112ad16d-0758-4c98-9fae-051745ae49d7|["<https://data-dev.skan-dev.io>:\n/login/oauth2/code/data-dev.skan-dev.io"]
For me, the https:// is already there.... Here is the GDCN_PUBLIC_URL env var:
Copy code
env:
          - name: "GDCN_PUBLIC_URL"
            value: "<https://data-dev.skan-dev.io>"
Any ideas?
r
the value
Copy code
"<https://data-dev.skan-dev.io>:\n/login/oauth2/code/data-dev.skan-dev.io"
stored in DB is wrong. It contains 
\n
instead of port number. Did you set 
EXTERNAL_PORT
by any chance? This is obsolete variable you should not use when you're already using 
GDCN_PUBLIC_URL
.
v
I did not use EXTERNAL_PORT... I tried to add a port number... after the public URL... but I could not... I will try to add a port number manually in the DB as you suggested... I added the value in the snippet above according to the instructions... not sure where it went wrong. Let me try some more...
r
no, the port should NOT be present if you use default 443
the GDCN_PUBLIC_URL must exactly match the URL you will use for accessing app (i.e. what points to ALB and resolves to its addresses). Also URL schema (https) must match what you'll use
v
yes... that's what I did
will circle back on that
r
You're right, there's a bug. While preparing some internal settings, one variable is incorrectly configured and we put a newline where it doesn't belong. I just fixed in our code base. Unfortunately, there's no simple workaround except not using default ports (443, 80) 😞 It should work if the GDCN_PUBLIC_URL contains some port value, eg. 8443 or anything else. If my fix gets merged soon, it will be fixed in the upcoming development build on Wednesday.
v
heh... thanks... fortunately getting the other idp to work was easy enough... I thought using the internal one was going to be easier, but it turned out to be moot
thanks!!!
Open in Slack
PreviousNext
Powered by