I've upgraded to Salesforce 4.0 from 3.x, and I'm using the Salesforce OAuth user-agent Provider module to provide like for like oauth authentication as per 3.x.

However even after revoking and then authorising Salesforce again, on the Salesforce Mapping UI interface for example I'm getting:

Error when connecting to Salesforce. Please check your credentials and try again: cURL error 6: Could not resolve host: sobjects (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

I've stepped through this API call and it seems like in the RestClient::apiCall function, it hits the following case:

    if (strpos($path, '/') === 0) {
      $url = $this->authProvider->getInstanceUrl() . $path;
    }
    else {
      $url = $this->authProvider->getApiEndpoint() . $path;
    }

In this case the call being made is sobjects/Lead/describe, so it follows the else condition. Following the logic for $this->authProvider->getApiEndpoint() it eventually relies on the state value salesforce.auth_identity.oauth_default to determine the identity URL. However this state value doesn't exist for me in the key_value table so $url doesn't get prepended with the an API endpoint, which explains CURL interpreting sobjects as the host.

And pointers as to how to set this state value? I've tried a bunch of different things but no luck.

CommentFileSizeAuthor
#24 sf_issue.patch905 bytesdhruveshdtripathi
#10 sf_issue.patch905 bytesbakulahluwalia

Comments

ThomWilhelm created an issue. See original summary.

aaronbauman’s picture

aaronbauman
he/him
commented

Sounds like the hook_update failed or wasn't run.
Did you run update.php / updb after upgrading to 4.x?
Have you tried re-saving the auth provider?

thomwilhelm’s picture

thomwilhelm commented

Yeah updb definitely got run, I don't have the output anymore but my schema version is 8402.

That's really weird I just revoked and re-authenticated and I've got that config now! I'm pretty sure I tried that before though, I've got a couple of other sites to test this on so I'll see what happens and if I can replicate at all.

Just out of interest when does the state value salesforce.auth_identity.oauth_default get set? Is it only after authenticating with Salesforce?

thomwilhelm’s picture

thomwilhelm commented

OK had a similar issue on another site, similarly the state salesforce.auth_identity.oauth_default didn't exist.

So I revoked the provider, and then re-authenticated. I got success but I still didn't have the salesforce.auth_identity.oauth_default set in key_value, although I did have salesforce.auth_tokens.oauth_default. However I then edited and saved the provider a second time and voila, I now have the state salesforce.auth_identity.oauth_default I need for the apiCall() methods to work.

I just replicated this by revoking my provider, then deleting the state value salesforce.auth_identity.oauth_default from key_value manually. The first time I authenticate, I don't get that state value back, it's only the second time it comes back. Hopefully this helps someone else out!

thomwilhelm’s picture

thomwilhelm commented
Related issues: +#3120102: Refresh SF auth token drush command should also store the identity on first token request

Just searching the issue queue I came across this issue I believe could be related to my situation. Having just the token and not the identity was the same state my site ended up in after upgrade, and only after authenticating a second time do I get the identity state.

I'll try find some time to dig around with a debugger in the next week or so!

nigelcunningham’s picture

nigelcunningham commented

I'm encountering this too. The update hook drops out because there's no salesforce_encrypt.profile state (line 375 of salesforce.install). If I'm reading things correctly, that's correct behaviour for the authConfig, where the decryption is being removed from the settings and the access token and refresh token.

The problem is that $tokenStorage->retrieveIdentity('oauth_default') returns NULL - even under 3.x so I assume what is needed is to run the code from the save hook in order to set a value for retrieveIdentity. I'm giving that a go.

bakulahluwalia’s picture

bakulahluwalia
Location Houston
commented

I was also facing same problem. Uninstall "Salesforce OAuth user-agent Provider" and install again fixed the problem.

agileadam’s picture

agileadam
Location Maine, USA
commented

The only way I could get this OAuth provider to work again was to uninstall the Salesforce OAuth user-agent Provider module, then reinstall it again. It's not ideal, but it worked. Thanks bakulahluwalia.

nigelcunningham’s picture

nigelcunningham commented

This seems to be a duplicate of https://www.drupal.org/project/salesforce/issues/3120102. I'll leave others to confirm/deny.

bakulahluwalia’s picture

bakulahluwalia
Location Houston
commented
StatusFileSize
new sf_issue.patch905 bytes

Finally after spending more than 15 hours I found the solution for this problem.
So, re-installing the module doesn't work all the time. The description of this problem is very informative. Which helped me narrow down the problem.
I uploaded the patch. Currently the patch has hard coded version number but once people will confirm that it's working for them then I will update it and make it dynamic.

I used this guide to solve this: https://blog.bessereau.eu/assets/pdfs/api_rest.pdf [page: 25]

aaronbauman’s picture

aaronbauman
he/him
commented
Version: 8.x-4.0 » 8.x-4.x-dev

Just ran into this issue myself.
Resolved by:
- Re-authing the auth provider
- Setting API version to Spring 20, instead of default "use latest"

I think this can happen when switching auth between sandbox and production.
For each new API version release there's some period of time where production doesn't yet support the latest available to sandbox.

We might fix this by having "use latest" actually use one version prior to latest, or having some kind of check that the version we're trying to use is actually supported in the connected environment.

aaronbauman’s picture

aaronbauman
he/him
commented

May also be related to recently fixed #3163385: $provider->refreshAccessToken doesn't keep refresh token

gregbeat’s picture

gregbeat commented

I still see this issue with the OAuth Sandbox user agent. bakulahluwalia's patch works, but I was hoping to use Aaron's solution of setting the API version in the UI. Unfortunately, with the Sandbox user agent, the select list for the API is empty.

I'm wondering if I can do something like this in settings.local.php
$config['salesforce.settings']['rest_api_version']['version'] = '46.0';

But not having any luck yet.

pablo.fredes’s picture

pablo.fredes commented

I had that issue and it was for a vpn that a had connected.

Edith.F’s picture

Edith.F commented

I am facing the same issue after upgrading from 3.x to 4.2, reinstalling the Salesforce OAuth user-agent Provider did not work for me.

Like the OP mentioned, the initial symptom is the "cURL error 6" message, which can be traced to "$this->authProvider->getApiEndpoint()" returning an empty string.

Continuing from there, I eventually came to the "save()" in SalesforceAuthProviderPluginbase.php. For my case, the statement "$form_state->getResponse() instanceof TrustedRedirectResponse" is always true, and the function never continues on to the part of saving the identify which is what the getApiEndpoint() relies on.

Searching through the code and I do not see another call to storeIdentify() except in the .install file.

My attempt to fix is by adding the same block of code to the callback function for "/salesforce/oauth_callback". The only part I have not figured out is how to find the "id" (Drupal's machine name for the auth provider) from the callback since that's how these identities are identified.

If I hard coded the machine name, I can get it work properly.

  1. Can someone confirm or comment on if this is the right path to fix this?
  2. Any idea on how I can carry the machine name (or any identifier of the auth provider) through the redirect to salesforce and back?

Thanks.

aaronbauman’s picture

aaronbauman
he/him
commented

\Drupal\salesforce_oauth\Plugin\SalesforceAuthProvider\SalesforceOAuthPlugin::submitConfigurationForm stores the machine name of the oauth provider into a session variable via tempstore.private service, before sending the redirect response to Salesforce.

Upon authenticating from Salesforce and redirecting back to Drupal, the oauth provider session value is retrieved in \Drupal\salesforce_oauth\Controller\SalesforceOAuthController::oauthCallback to complete the oauth handshake.

Storing the token and identity are handled by \Drupal\salesforce\SalesforceAuthProviderPluginBase::requestAccessToken (via \OAuth\OAuth2\Service\Salesforce::requestAccessToken in lusitanian/oauth package), which is called by SalesforceOAuthController::oauthCallback.

IMO I recommend using JWT provider because it is much more straightforward and reliable.

Edith.F’s picture

Edith.F commented

Hi Aaron,

Thank you for the reply. We haven't switched to JWT yet, I will take a look at it.

I followed your comment and here is what I found:

In \OAuth\OAuth2\Service\Salesforce::requestAccessToken, requestAccessToken is not defined, so it is inheriting the method from \OAuth\OAuth2\Service\AbstractService::requestAccessToken.

And in there, I see that it does the usual request to get the token and store it by calling storeAccessToken. However, it does not call on storeIdentity which is where the getApiEndpoint is getting the URL from.

Maybe the call to storeIdentity is needed somewhere in this oauthCallback process when authorizing a new auth provider?

Thanks.

aaronbauman’s picture

aaronbauman
he/him
commented

\Drupal\salesforce\SalesforceAuthProviderPluginBase::requestAccessToken calls refreshIdentity directly after calling the parent method, per #3102133: Refresh identity whenever token is refreshed

This is only in the dev branch right now, so maybe it's time to cut a new release.

Edith.F’s picture

Edith.F commented

Ah, I see. Thank you, Aaron!

nigelcunningham’s picture

nigelcunningham commented

I am (again/ still) facing the same issue, so "Yes please" to a new release, thanks Aaron :)

nigelcunningham’s picture

nigelcunningham commented

I've now switched to 4.x-dev and can confirm this gets my install working. Thanks!

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Active » Fixed

Pushed new releases today, 4.3 and 5.0.0-beta1
Gonna call this fixed unless someone can provided updated steps on how to reproduce the issue

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

dhruveshdtripathi’s picture

dhruveshdtripathi commented
StatusFileSize
new sf_issue.patch905 bytes

Upgrading version to 48.0 from 46.0