Closed laurakolker closed 10 months ago
laurakolker
commented
4 years ago Follow up URL details for the redirect to test.salesforce.com problem
If the force:org:open command output says the URL is: https://computing-data-290-dev-ed.cs22.my.salesforce.com/secur/frontdoor.jsp?sid=00D170000003j8T!ARYAQJjnRsQF51nmV3.pUYEwCFd7aVuCD0W3y_TNc1g5du7D60IpnLK8gjvyjpbhMFRJejeDR_6D649wSExtIvzSGGlTz4lD&retURL=lightning
aheber
commented
4 years ago I see this problem from time to time, it almost seems seasonal, it will be bad for a while (every 5th scratch org or so) then it will calm down and almost never show up. I don't think it is the CLI but rather the scratch org provisioning process. It seems like the access token returned from provisioning isn't properly web-enabled and will only work for the API.
Right now we're handling this by clearing out the access token from the credentials held in ~/.sfdx/ORG_NAME.json the running sfdx force:org:open -r -u ORG_NAME. This will cause it to get a fresh access token using the refresh token stored in the same credentials. Not all commands have the ability to regenerate the token but force:org:open seems to do the job just fine.
Might be best to report it in the SFDX trailblazer community to best get it in front of that team.
It would be nice if the CLI gave a clean way to refresh the access token without having to have something manipulate the stored credentials that in theory we shouldn't be messing with.
amphro
commented
4 years ago Ya, this is usually the provisioning process and getting tokens for domains that aren't fully propagated; hence the DomainNotPropegated error but often shows itself by just redirecting to the login page. I don't think there is a good way for the CLI to detect these, but we do try to wait for lightning domain propagation with org:open.
It would be nice if the CLI gave a clean way to refresh the access token without having to have something manipulate the stored credentials that in theory we shouldn't be messing with.
Agreed you don't want to mess with the auth but I get the desire. The sfdx force:org:display command will refresh the token but only if it is currently expired. Having a token refresh seems like a possibility but not sure it will make it on the roadmap unless there is enough demand. Something that could also easily be a CLI plugin.
laurakolker
commented
4 years ago Thanks for the info. That's helpful to know. fwiw, I've taken to generating a password with sfdx force:user:password:generate and then just logging in which works even though its kind of :disappointed: :woman_shrugging: @aheber : when you mention it might be best to report to the SFDX Trailblazer, is that a request for me to do that? I'm happy to report things to the right place, but I don't actually know where that is. I just kind of stumbled on this github by accident. (Or maybe you're making an internal note and not talking to me at all which is fine :) ). Anyway, if there's a better place to report this, give me a link and I'll do my best. Thx!
aheber
commented
4 years ago @laurakolker, sorry I wasn't clear. Yes, I would recommend you report in the DX group: https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000HTp1
I'm not part of the CLI team or anything. I have reported in the past and it gets fixed for a while, that group does better for reporting problems with the scratch orgs themselves vs. the CLI DX tools. I don't have any orgs producing the error because of my workaround so I don't have a good org to submit to them for testing.
If you can make the problem happen that take the org ID and include that in the post so they can review and troubleshoot.
@amphro , agreed it would be a good plugin. It is on my roadmap ;)
saurabh-deep
commented
4 years ago We have also been seeing this occasionally with scratch orgs. Sometimes, it is resolved if we delete the scratch org and create again. Sometimes, it persists for some time and then gets resolved on it's own. Somehow, even generating the scratch org password and logging in with that doesn't seem to work.
mitchspano
commented
3 years ago I am also experiencing this on a pretty regular basis. @aheber 's suggesion to clear out the access token did not work for me either.
omazhar
commented
3 years ago We are also experiencing this issue when opening sandboxes, right after they have been created. But as experienced by others, the problem is intermittent. Sometimes the force:org:open command will take you to the home page authenticated, while every once in a while it will redirect you to the login screen.
cristiand391
commented
10 months ago Closing this since we haven't got any report about this in +2 years.
sf does a DNS check to ensure it was propagated before opening it but if someone starts getting this error please log a new issue.
Summary
Sometimes a scratch org will not authenticate properly with force:org:open. I've had some that redirect to test.salesforce.com login screen (with these, if I remove everything but the base url from the url bar, sometimes it will redirect to the scratch org authenticated.) Once it redirected to a classic error screen.
Steps To Reproduce:
I'm not sure what parameters cause this to occur. Its an intermittant problem with some scratch orgs. The command is sfdx force:org:open
Expected result
Browser opens to scratch org without requiring the user to authenticate
Actual result
Intermittantly, either redirect to test.salesforce.com login screen or a classic error screen (screenshot included)
Additional information
SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.45.1-bc18d49798 linux-x64 node-v10.15.3
SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) salesforcedx 47.18.0 (core) ├─ salesforcedx-templates 47.19.0 (core) └─ salesforce-alm 47.16.0 (core) sfdx-cli 7.45.1 (core)
OS and version: Ubuntu PopOS 19.10