Hello again we bumped from 0 9 3 to 0 9 4 as there were some DataHub #troubleshoot

Hello again, we bumped from 0.9.3 to 0.9.4 as ther...

damp-greece-27806

12/21/2022, 5:46 PM

Hello again, we bumped from 0.9.3 to 0.9.4 as there were some bug fixes. Previously we weren’t getting any logs from datahub-frontend, but that’s resolved in 0.9.4. Now that we can see the log output, we see that the OIDC process is wanting a

code_verifier

parameter that we’re not passing. We’re not seeing how we can pass that. One thing to note/check is that datahub is using pac4j 4.5.7 (https://github.com/datahub-project/datahub/blob/master/build.gradle#L156) and pac4j recently released 5.1.1 with notes about fixing PKCE OIDC flow issues (https://www.pac4j.org/docs/release-notes.html), in case this problem is from an underlying source. Any help you all can provide would be appreciated, our datahub cluster has been down for 2 weeks now because of this

damp-greece-27806

12/21/2022, 5:48 PM

oh, and we’re using Google for auth, in case that’s pertinent

astonishing-answer-96712

12/21/2022, 6:07 PM

Hi @damp-greece-27806 this seems to be a bug in the most recent release- we’re working on getting a fix out right now, please bear with us!

damp-greece-27806

12/21/2022, 6:29 PM

thank you!

brainy-tent-14503

12/22/2022, 3:03 AM

Please see if this frontend image fixes the issue for you

<http://docker.io/linkedin/datahub-frontend-react:2a182f4|docker.io/linkedin/datahub-frontend-react:2a182f4>

damp-greece-27806

12/22/2022, 3:06 PM

ok I’ll try it out within the next half hour

damp-greece-27806

12/22/2022, 4:25 PM

hey, so I got the same outcome, but a different error. It seems like it goes through several provisioning things and finds me in all the requests that it makes, except for the last one:

Copy code

2022-12-22 16:18:10,401 [application-akka.actor.default-dispatcher-9] DEBUG auth.sso.oidc.OidcCallbackLogic - Attempting to provision user with urn urn:li:corpuser:hassan.shahid
2022-12-22 16:18:10,404 [R2 Netty Scheduler-2-1] DEBUG c.l.r.t.h.c.ExponentialBackOffRateLimiter - Running rate limited task at 1671725890404 with period 0
2022-12-22 16:18:10,410 [R2 Nio Event Loop-1-2] DEBUG c.l.r.t.h.c.rest.RAPResponseHandler - /x.x.x.x:xxx: handling a response
2022-12-22 16:18:36,389 [R2 Netty Scheduler-2-1] DEBUG c.l.r.t.http.client.AsyncPoolImpl - /x.x.x.x:xxx/xxx: disposing 1 objects due to idle timeout
2022-12-22 16:18:36,389 [R2 Nio Event Loop-1-2] DEBUG c.l.r.t.h.c.rest.RAPResponseHandler - /x.x.x.x:xxx: idle channel closed

brainy-tent-14503

12/22/2022, 5:26 PM

That is looking like some kind of timeout provisioning the user which it would only be able to identify after the oidc flow is validated. It would have extracted the username from the email at this point. I believe its a non-oidc related issue at this point despite still being in the oidc controller after successful auth.

damp-greece-27806

12/22/2022, 5:28 PM

do you know what/where it’s trying to provision?

brainy-tent-14503

12/22/2022, 5:28 PM

The user

urn:li:corpuser:hassan.shahid

brainy-tent-14503

12/22/2022, 5:28 PM

which if it already exists sure succeed as well

damp-greece-27806

12/22/2022, 5:29 PM

I mean to say, what system is trying to provision from that would be timing out?

damp-greece-27806

12/22/2022, 5:40 PM

also, are you saying this is now an issue on our side, or is it still within the realm of datahub?

brainy-tent-14503

12/22/2022, 6:10 PM

The provisioning user is on your side, you should be able to got to another issue which is being debugged here. In that thread, the user provisioning worked and am now debugging a missing consent page that is required by google.

2 Views

Open in Slack

Previous Next