This PR adds support for logging in to different domains, specifying an optional domain flag during the login process. This flag is optional and everything should work as before when only the subdomain is specified.
This feature is useful for working with development environments. Let's say that a development environment is hosted on the example.com domain, now it is possible to do
zcli login -s zendesk-subdomain -d example.com -i
and zcli will call the APIs using the https://zendesk-subdomain.example.com URL instead of https://zendesk-subdomain.zendesk.com.
It is also possible to use the ZENDESK_DOMAIN environment variables for CI/CD or unattended login.
This new feature works as well with the profiles command. The profiles:list will display only the subdomain for profiles where the domain wasn't specified during the login (as before), and it will display both the subdomain and the domain if the domain was specified during the login.
The profiles:use and profiles:remove commands will work as before specifying only the subdomain or subdomain.domain in the case the domain was specified during the login.
For example, if the user logged in to these accounts:
zcli login -s test -izcli login -s account2 -izcli login -s test -d example.com -izcli login -s another-account -d example.com -i
The output of profiles:list will be:
Accounts
──────────────────────────────────
test
account2
test.example.com
another-account.example.com
And it will be possible to call profiles:use or profiles:remove passing either test, account2, test.example.com or another-account.example.com.
c90f0b3 feat: added support for logging in to different environments
This PR changes how profiles are stored in the config. Before we had an object with only the subdomain ({subdomain: string}) and now it can store the optional domain as well ({subdomain: string, domain?: string}).
It also changes how things are stored in the SecureStore, where the key for storing credentials for profiles with only a subdomain will be the subdomain itself (as before, to make it backward compatible). The key will be instead subdomain.domain for profiles with both, and this makes it possible to use the same subdomain with different domains (like test and test.example.com as shown in the previous examples).
When the ZENDESK_SUBDOMAIN env variable is set, the domain will be set to the ZENDESK_DOMAIN env variable if set, or it will be empty otherwise. This is to avoid reading the domain for the current logged-in profile if an unattended login is made passing the ZENDESK_SUBDOMAIN env variable and omitting the ZENDESK_DOMAIN one.
Checklist
[x] :guardsman: includes new unit and functional tests
etanxing
commented
11 months ago
Description
This PR adds support for logging in to different domains, specifying an optional
domainflag during the login process. This flag is optional and everything should work as before when only the subdomain is specified.This feature is useful for working with development environments. Let's say that a development environment is hosted on the
example.comdomain, now it is possible to dozcli login -s zendesk-subdomain -d example.com -iand
zcliwill call the APIs using thehttps://zendesk-subdomain.example.comURL instead ofhttps://zendesk-subdomain.zendesk.com.It is also possible to use the
ZENDESK_DOMAINenvironment variables for CI/CD or unattended login.This new feature works as well with the profiles command. The
profiles:listwill display only the subdomain for profiles where the domain wasn't specified during the login (as before), and it will display both the subdomain and the domain if the domain was specified during the login.The
profiles:useandprofiles:removecommands will work as before specifying only the subdomain orsubdomain.domainin the case the domain was specified during the login.For example, if the user logged in to these accounts:
zcli login -s test -izcli login -s account2 -izcli login -s test -d example.com -izcli login -s another-account -d example.com -iThe output of
profiles:listwill be:And it will be possible to call
profiles:useorprofiles:removepassing eithertest,account2,test.example.comoranother-account.example.com.c90f0b3feat: added support for logging in to different environmentse6761a4chore: removed useless undefinedDetail
This PR changes how profiles are stored in the config. Before we had an object with only the subdomain (
{subdomain: string}) and now it can store the optional domain as well ({subdomain: string, domain?: string}).It also changes how things are stored in the
SecureStore, where the key for storing credentials for profiles with only a subdomain will be the subdomain itself (as before, to make it backward compatible). The key will be insteadsubdomain.domainfor profiles with both, and this makes it possible to use the same subdomain with different domains (liketestandtest.example.comas shown in the previous examples).When the
ZENDESK_SUBDOMAINenv variable is set, the domain will be set to theZENDESK_DOMAINenv variable if set, or it will be empty otherwise. This is to avoid reading thedomainfor the current logged-in profile if an unattended login is made passing theZENDESK_SUBDOMAINenv variable and omitting theZENDESK_DOMAINone.Checklist