Remove GaiaOauthClient and GaiaUserEmailFetcher from remoting.

Remove GaiaOauthClient and GaiaUserEmailFetcher from remoting.

The OAuth functionality remoting needs is implemented in google_api module.
There is no need to duplicate it in remoting.

BUG=147565
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=164461

[rmsousa, 2012-10-24 23:18:47]

(drive-by)

Funny enough, I had just noticed the same thing yesterday, while digging through
the oauth code, and was thinking about doing it later this week - guess you were
faster than me :)

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
File remoting/host/signaling_connector.cc (right):

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
remoting/host/signaling_connector.cc:227: gaia::OAuthClientInfo client_info = {
I'm not sure if we should move the client id/secret here. If in the future the
webapp (it2me) and the host end up using different OAuth flows (say, installed
native app for the host, web application flow for the webapp), they may have to
use different client ids (or we may want to use different ones intentionally for
other reasons).

[Sergey Ulanov, 2012-10-24 23:31:30]

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
File remoting/host/signaling_connector.cc (right):

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
remoting/host/signaling_connector.cc:227: gaia::OAuthClientInfo client_info = {
On 2012/10/24 23:18:47, rmsousa wrote:
> I'm not sure if we should move the client id/secret here. If in the future the
> webapp (it2me) and the host end up using different OAuth flows (say, installed
> native app for the host, web application flow for the webapp), they may have
to
> use different client ids (or we may want to use different ones intentionally
for
> other reasons).

It's likely that we won't need to use different client IDs, but if it ever turns
out that we do need it then it will be easy to add client_info parameter back.

[simonmorris, 2012-10-25 06:37:40]

lgtm with optional suggestion.

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
File remoting/host/signaling_connector.cc (right):

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
remoting/host/signaling_connector.cc:120:
signal_strategy_->SetAuthInfo(oauth_credentials_->login,
Consider moving this where it was before, after the email address is checked.
That way you won't set a signal strategy that uses an invalid email address.

[Wez, 2012-10-25 19:50:43]

On 2012/10/24 23:31:30, sergeyu wrote:
>
http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
> File remoting/host/signaling_connector.cc (right):
> 
>
http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
> remoting/host/signaling_connector.cc:227: gaia::OAuthClientInfo client_info =
{
> On 2012/10/24 23:18:47, rmsousa wrote:
> > I'm not sure if we should move the client id/secret here. If in the future
the
> > webapp (it2me) and the host end up using different OAuth flows (say,
installed
> > native app for the host, web application flow for the webapp), they may have
> to
> > use different client ids (or we may want to use different ones intentionally
> for
> > other reasons).
> 
> It's likely that we won't need to use different client IDs, but if it ever
turns
> out that we do need it then it will be easy to add client_info parameter back.

We will have to move to different Client Ids for the two, before too long,
actually.

[Sergey Ulanov, 2012-10-26 00:30:35]

Will land this change after crrev.com/11271038

[Sergey Ulanov, 2012-10-26 21:05:00]

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
File remoting/host/signaling_connector.cc (right):

http://codereview.chromium.org/11273024/diff/1/remoting/host/signaling_connec...
remoting/host/signaling_connector.cc:120:
signal_strategy_->SetAuthInfo(oauth_credentials_->login,
On 2012/10/25 06:37:40, simonmorris wrote:
> Consider moving this where it was before, after the email address is checked.
> That way you won't set a signal strategy that uses an invalid email address.

Done.

[commit-bot: I haz the power, 2012-10-26 21:10:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sergeyu@chromium.org/11273024/7001

[commit-bot: I haz the power, 2012-10-26 23:14:04]

Commit queue patch verification failed without an error message.
Something went wrong, probably a crash, a hickup or simply
the monkeys went out for dinner.
Ping the relevant dude on a on-needed basis.