Skip to content
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

Make site dynamic to support SFDX scratch orgs #26

Open
topherlandry opened this issue Apr 11, 2018 · 6 comments
Open

Make site dynamic to support SFDX scratch orgs #26

topherlandry opened this issue Apr 11, 2018 · 6 comments

Comments

@topherlandry
Copy link

I'm not sure what the best way to accomplish this is, but with SFDX scratch orgs the site needed for OAuth is not login.salesforce.com but whatever the instance URL of the scratch org is. This is causing problems for me with doing development with SFDX.

One way I could solve this is by loading client_options.site from an environment variable if it exists and using login.salesforce.com otherwise.

I'm happy to do the work needed for a PR on this one, but I'm looking for a little bit of a suggestion just to make sure it fits with the project and isn't rejected when submitted.

@realdoug
Copy link
Owner

realdoug commented Apr 12, 2018

Hm, good question. I think that's something that we need to know from omniauth itself. Can you pass it a dynamic value for client_options.site. First place I'd look is to see if any other omniauth plugins use a dynamic endpoint like this.

If it isn't supported, I guess the fallback would be an env variable as you described.

@topherlandry
Copy link
Author

I'm going to submit a PR to omniauth-oauth2 first to make site loaded the same way as the client key and secret. If that's accepted then updating the gem here should make that easier to load dynamically.

Otherwise I can submit a fallback PR here.

@swagner2
Copy link

swagner2 commented Aug 31, 2018

So would this cause our issue when we log into our app, with Sandbox accounts for testing, we're seeing the developer account in the app instead of the test account's?

  • we've tried new test accounts (with their own email credentials)
  • private browser sessions
  • login with the sandbox URL before logging into the app
    Every time, the account reverts to the developer account

@kriom
Copy link

kriom commented Nov 7, 2018

Perhaps my PR can help #28 ?

@realdoug
Copy link
Owner

realdoug commented Nov 8, 2018

@kriom thanks for contributing. Will take a look this week.

@adimasuhid
Copy link

A simple solution without using other strategies:

Rails.application.config.middleware.use OmniAuth::Builder do
  if ENV['SALESFORCE_SCRATCH_ORG_URL'].present?
    OmniAuth::Strategies::Salesforce.default_options[:client_options][:site] = ENV['SALESFORCE_SCRATCH_ORG_URL']
  end

  provider :salesforce, ENV['SALESFORCE_OAUTH_KEY'], ENV['SALESFORCE_OAUTH_SECRET']
end

This makes the provider still salesforce (ie auth/salesforce, auth/salesforce/callback) while being able to utilize scratch orgs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants