-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
editing oauth connector fields fails silently #7864
Comments
Error I'm seeing in the
|
|
This is the request body that gets sent when trying to edit the connector settings:
this doesn't include The 500 error from clicking This appears to be an issue with the Oauth implementation for when a connector is updated. @ChristopheDuong @jamakase could you take a look? |
With OAuth feature on cloud, In the past, this was handled on a special However, in #7917 I recently removed the web_backend injection logic and made it so these global parameters are returned along with outputs from OAuth flow (masked)
So, I hope we shouldn't see this issue anymore for connector created after upgrading to that 0.32.1-alpha+ version (connector created before the upgrade probably would need to go through the oauth flow) Unless there is some extra logic on the Front-end to handle this? @jamakase |
I believe that will work as is as soon as they are returned from backend. Let's keep it open, I will verify that it works fine on new version. |
Cloud is on 0.32.0 version now and is throwing an error when going through oauth:
Which returns:
I am guessing it's due to #7325 not being fully reverted in the front-end somehow? cc @avida |
@ChristopheDuong It was reverted by #7968 Also there were following commit on updating package-lock.json file. |
It seems like we need to deploy |
@ChristopheDuong @jamakase @avida It looks like we have deployed cloud to
and if I then try to click
and I get redirected to a page that just says So it seems like oauth might be broken even worse now. Can someone take a look? |
Yes, I've noticed that too, maybe it's related to #7650 ? |
@ChristopheDuong i don't think that issue could be a root cause of this behavior. refresh_token will be saved after first successful request. Working on it. |
Maybe related, but in that issue it looks like the first |
That's because you have a third one that succeeded! |
@ChristopheDuong problem is in this PR #7917. We can't just remove web_backend. We do not send Based on the requirements everything within |
Just verified that number of Is it correct that from now, the output of complete_oauth_flow call will always include oauthFlowInitParameters ( maybe in masked way )? If yes, I could add a qfix to treat |
yes, it will always include them masked from now on. It's also in line with how it works with the new protocol changes here #7915 it makes the backend code easier that way too |
@jamakase did you test if this fixes the oauth issue? If so should we release OSS so that we can use this fix in cloud? |
Yep, I verified it numerous times for Salesforce connector and the backend that is currently deployed in dev env. |
I tested on cloud 0.32.2-alpha and it works for me too when:
|
To reproduce with Salesforce on cloud:
I'm also getting a 500 error when clicking on the "Authenticate your Salesforce account" button in the edit page. Not sure if that's related or not.
I think there are up to three things to fix here:
The text was updated successfully, but these errors were encountered: