Request rides

[steverob]

This is a really neat tool. I was hoping I could contribute a feature to request rides as well. But I was little surprised this has not been attempted here yet. So just wanted to check with you @jaebradley whether you think its a good idea or not?

Once you give me the go ahead, I'll start working on this. 👍 Thanks.

[jaebradley]

@steverob thanks for the feedback - and really good idea (definitely a product gap for this CLI).

I actually thought about requesting rides via the command line but it's non-trivial. I'm sure you've looked at the developer docs. Basically, the biggest technical task is implementing OAuth2 (would be interested in your take on how to successfully accomplish this).

A complicating factor in all of this is that I made the decision to expose the server token (#19) for ease of use on the consumer-side and also because all of the requests that this CLI makes are GETs which do not impact user state. Also, on the security-side of things, the Uber developer tools allow your app to only have certain scopes and I deliberately chose scopes that did not modify data.

I feel queasy about building user mutating actions on top of an exposed server token. One solution is to create a new Uber developer app and sufficiently obfuscate its server token (as I should have done originally) / ask people to supply their own tokens, and perform the relevant actions on their behalf. Both of these present interesting technical challenges in their own right - would also love your feedback!

Looking forward to the discussion!

[manoharprabhu]

Presenting the driver's location in realtime on a CLI is also challenging.

[steverob]

@jaebradley Hey, thanks for your reply. And sorry about the late reply.

Yes I've looked into the docs and OAuth2 is the trickiest bit here. It looks like we have to go through a web flow to get the auth tokens. Wish Uber had something like what Dropbox had where they would simply display the request token which can be pasted into the console when authorizing dropbox cli.

There is something we could do though but its very hacky. We could setup an application on Uber and set the redirect_url to some place like RequestBin or we could run a simple static web app which would simply display the code given by Uber and then let our users paste it back into the console and we could take over the access token requesting part.

But now we run into the issue of having our keys exposed (client_id and client_secret) in the repo which is not good. If we let our users supply their own keys, we would need to have them create their own Uber application - which is again not optimal IMO.

Huh, this is pretty tricky..

[steverob]

@jaebradley any further thoughts? :) sorry if I'm bugging you. I dont wanna start working on something that might not be the right thing for us at this time.

[jaebradley]

@steverob hey thanks for bumping this thread - I've been busy consolidating code in some other repos and haven't had time to reinvestigate this.

Personally / selfishly, my next goals with this project are to increase the code quality to a point where I'm comfortable - something I hope to accomplish in the next one or two months (slightly sandbagging here).

After that, I'll start considering the technical challenges that have been presented in this thread but the way I'm thinking about all this is that before I do any additional feature work, I'd like to consolidate the code base.

That being said, I welcome you to tackle some of the technical tasks around OAuth 2, etc. and would love to collaborate.

[agraebe]

@steverob @jaebradley this is probably not the best option and not 100% thought out but how about this:

• you set the redirct_url in your dashboard to localhost:8080
• the first usage of request-related features prompts the user to open up the auth page to grant your app access
• simultaneously, you spin up an express app to listen for the callback as soon as user approves the auth request
• the express app receives the code from the callback and exchanges it for an access_token
• you encrypt the access_token (with some unique local props) and store it in a local config file
• in the meantime, the redirect page (localhost:8080) returns "thank you, you can go back to the cli" with a close page button
• you close the express app instance as it's not needed anymore
• for all future calls to request-related features, you decrypt the access_token and use it for the calls

worth noting that you'd need to have the client_secret to exchange the auth code for an access_token... Ideally, users would have an own app and basically set the server_token and their client_secret before using uber-cli.