4

When setting up oAuth on an external system you need to provide a Callback URI for the external oAuth to redirect to. This URI must be static and passed in as a parameter to the oAuth call.

When developing a managed package one cannot modify the callback based on the pod for each customer. Previously I used ap1 and was incorrect in thinking it meant "Access Point" years ago. I never really went and looked but now I know it is Asia Pacific on my what a dumb move on my part....

So, If I am using Visualforce to start the oAuth process and then handle the redirect to make the token request, what URL should I put in the external system so it always resolves to the correct pod and returns to the VF page without requiring the user to login (session is still valid for the browser).

External System https://xxx.com/authorize

oAuth Callback URL is defined and must be static. i.e. (pod is just an example)

https://ap1.salesforce.com/apex/authHandler

The callback is the URL the code is sent back to once the user approves the access

Salesforce

VF Page (authHandler) controls the entire process.

  1. On load it redirect to the external system.
  2. When redirected to the callback URL defined in the external system the VF page sees the code in the parameters and make an HTTPRequest to get the access and refresh tokens

Question

  1. What URL do I use for the callback that will resolve and get back to the VF page without being redirected to login.salesforce.com?ec=xxxxx and requiring login. The session is still valid so it does not ask for a password.

If the above is not possible I guess I could create a site page on our business org to handle the redirects and serve as the static URL

1 Answer 1

4

It depends on the OAuth2 implementation that you're authenticating against, but generically speaking, login.salesforce.com should work for production instances, test.salesforce.com should work for sandbox instances. What happens is that when you hit either login server, if there's a path afterwards, the login server tries to forward them to their existing session.

For your managed package, your callback URL should look like this:

https://login.salesforce.com/apex/myns__mypage

Or for sandboxes:

https://test.salesforce.com/apex/myns__mypage

Since most OAuth2 implementations only allow one callback URL, you'll need to have two separate "apps", one for production, and one for sandboxes.

Your VF page should query the Organization object beforehand to determine if you're in a sandbox or not.

6
  • I have tried that and it requires login during the callback https://login.salesforce.com/?ec=302&startURL= is what it ends up at (URL removed by me). It does transform to na30.salesforce.com but then 302's to the login page
    – Eric
    Commented May 4, 2017 at 16:10
  • @Eric Make sure you're logged in only once? I don't think normal users should experience this problem, but we developers tend to have sessions laying about all over the place. Try doing your login incognito and see if that changes things.
    – sfdcfox
    Commented May 4, 2017 at 16:13
  • It works when my domain is not enabled. Redirects on the callback with mydomain enabled. The console shows redirect to na30 is hit then 302 to login.
    – Eric
    Commented May 4, 2017 at 16:13
  • Do you have "forward urls" enabled and "require login from domain" disabled? The login url is working in my developer org that has a managed package.
    – sfdcfox
    Commented May 4, 2017 at 16:15
  • I was logged out of every org when I was trying. I opened Firefox which I have not used in days and it did indeed work. Seems even though logged out the cookies or something caused confusion on the redirect. Thanks. Appreciate the confirmation that login.salesforce.com should work for the customer experience
    – Eric
    Commented May 4, 2017 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .