Add ability to login to a dev endpoint that uses a self-signed cert

[elilevine]

(Issue #39)

[ddollar]

How about logging into dev servers like this:

$ force login https://CLIENTID@SERVER:PORT

[elilevine]

That's not a bad idea. Client id is rather long, so having to type that into the command line every time would be a pain. I guess users can create an env variable to hold that. https:// can be assumed and dropped.

Also, how to handle self-signed certs? One option is use the additional dev endpoint, like I have done and allow self-signed certs for it. Another option is to assume that if the third command line argument is not a known endpoint, it's a dev endpoint with the specified connection params. Third option is to allow self-signed certs for all endpoints, which is bad.

I like the first option, which makes things more explicit:

$ force login dev CLIENTID@SERVER:PORT

[ddollar]

I was thinking drop the dev and keep the https://. If the user specifies an exact URL, drop the verification around the certificate. I'd imagine that you wouldn't type the CLIENTID but would instead copy/paste or make an alias.

$ force login https://CLIENTID@SERVER:PORT

[elilevine]

Dropping dev is fine. Why not assume HTTPS and drop it from the command line URL? We have to break apart the URL anyway, since we need to use CLIENTID in a param and add the /services/oauth2/authorize to construct the actual login URL. I don't see a use case where a user might want to run this over HTTP (in fact, oauth2 requires HTTPS).

[ddollar]

Dropping the https:// is fine with me, though you should probably make it work either way since often pasted URLs include it unexpectedly.

[dcarroll]

I think if we are going to go this direction we should consider change the
oauth flow to username and password, or at a minimum make username password
flow an option. It would enable more automation by not having the web
server flow where a person needs to click a button.

On Tue, Nov 26, 2013 at 11:31 AM, Eli Levine notifications@github.comwrote:

Dropping dev is fine. Why not assume HTTPS and drop it from the command
line URL? We have to break apart the URL anyway, since we need to use
CLIENTID in a param and add the /services/oauth2/authorize to construct the
actual login URL. I don't see a use case where a user might want to run
this over HTTP (in fact, oauth2 requires it).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-29323972
.

Thanks,
Dave

[ddollar]

Wouldn't usename/password flow require exposing the Oauth client secret in the open codebase?

[noeticpenguin]

Ignorant wishful thinking here, would user/pass flow with SF.identity 2factor token be possible?

-- 
Kevin Poorman
Sent with Airmail

On November 26, 2013 at 2:37:21 PM, Dave Carroll (notifications@github.com) wrote:

I think if we are going to go this direction we should consider change the
oauth flow to username and password, or at a minimum make username password
flow an option. It would enable more automation by not having the web
server flow where a person needs to click a button.

On Tue, Nov 26, 2013 at 11:31 AM, Eli Levine notifications@github.comwrote:

Dropping dev is fine. Why not assume HTTPS and drop it from the command
line URL? We have to break apart the URL anyway, since we need to use
CLIENTID in a param and add the /services/oauth2/authorize to construct the
actual login URL. I don't see a use case where a user might want to run
this over HTTP (in fact, oauth2 requires it).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-29323972
.

Thanks,
Dave
—
Reply to this email directly or view it on GitHub.

[dcarroll]

Good point David, will discuss on a different issue.

On Tue, Nov 26, 2013 at 11:38 AM, Kevin Poorman notifications@github.comwrote:

Ignorant wishful thinking here, would user/pass flow with SF.identity
2factor token be possible?

Kevin Poorman
Sent with Airmail

On November 26, 2013 at 2:37:21 PM, Dave Carroll (notifications@github.com)
wrote:

I think if we are going to go this direction we should consider change the
oauth flow to username and password, or at a minimum make username
password
flow an option. It would enable more automation by not having the web
server flow where a person needs to click a button.

On Tue, Nov 26, 2013 at 11:31 AM, Eli Levine notifications@github.comwrote:

Dropping dev is fine. Why not assume HTTPS and drop it from the command
line URL? We have to break apart the URL anyway, since we need to use
CLIENTID in a param and add the /services/oauth2/authorize to construct
the
actual login URL. I don't see a use case where a user might want to run
this over HTTP (in fact, oauth2 requires it).

—
Reply to this email directly or view it on GitHub<
https://github.com/heroku/force/pull/40#issuecomment-29323972>
.

Thanks,
Dave
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-29324670
.

Thanks,
Dave

[ryanbrainard]

Direct un/pw login (i.e. without any OAuth) is also possible with the SOAP API. Its not really recommended anymore, but if you want to avoid storing secrets in the client, its an option.

[dcarroll]

@ryanbrainard I've got something coded up for using the SOAP login.

force login (default endpoint using oauth)
force login test (sandbox endpoint using oauth)
force login username password (default endpoint using SOAP)
force login test username password (sandbox login using SOAP)

After the login is successful, the correct REST endpoint is constructed to the ID and that user data is retrieved, converging back to the REST login flow.

[ryanbrainard]

@dcarroll does it also work with non-production, non-test login URLs (i.e. internal dev/testing instances)?

[dcarroll]

As well as the current OAuth does. I don't think we took the pull request
for random endpoints.

On Tue, Dec 10, 2013 at 12:58 PM, Ryan Brainard notifications@github.comwrote:

@dcarroll https://github.com/dcarroll does it also work with
non-production, non-test login URLs (i.e. internal dev/testing instances)?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/40#issuecomment-30267232
.

Thanks,
Dave

[dcarroll]

Yup, so I fixed it to work on non production too

force login https://na1-blitz01.soma.salesforce.com username password
force login na1-blitz01.soma.salesforce.com username password

As long as the hostname can be resolved. It does pose an issue with the certificate validation though. Not sure how to solve that.

[elilevine]

@ddollar, @dcarroll, how does this pull request look? Let me know if there other changes that need to be made. I'd like to advertise the tool to SFDC devs for internal development and it would be nice if I didn't need to point them to my fork.

[atorman]

@dcarroll I have a great use case for adding the username/pw flags. I have an object that exists in multiple orgs collecting the same type of data on an org by org basis. I want to write a bash script that involves logging into multiple orgs, running a SOQL query on the same object, pulling down the data into a CSV and merging it together. Unfortunately, right now I have to go through the browser authorization process which I can't automate across multiple orgs without the username/pw flags. Any chance this pull request will get in there?