library is overeager to authenticate

[GoogleCodeExporter]

See 
http://stackoverflow.com/questions/8796696/accessing-google-ruby-api-in-public-m
ode

When the library lacks an access token, and client.authorization has not 
separately been set to nil explicitly, it returns "ArgumentError: Missing 
access token."

Instead, it should simply attempt the connection unauthenticated, resulting in 
access denied errors if authentication was required.

Original issue reported on code.google.com by sai...@gmail.com on 10 Jan 2012 at 2:40

[GoogleCodeExporter]

Well, let's step back a bit. Certainly this would be more convenient for the 
unauthenticated use-case, but let's consider the far more common authenticated 
use-case.

If you make the request in the case where authorization is required without 
providing the access token, you'll get an authorization error back from the 
server. Authorization is consistently the hardest part of the system to 
understand and having clear error messages on the client side is critical. If 
as a developer, I think I've completed all the steps for authorization (but 
haven't) and I try to make a request the requires authorization, the 'Missing 
access token' error is exactly the information I need.

It might be possible for us to expand the discovery data for each method to 
additionally indicate when a method can be used without going through OAuth, 
but I don't think that's possible today. Right now we just tell you what scopes 
are required. But even that information isn't terribly useful in many cases, 
because the machine logic is something like this: If you're making a call to 
method X and it specifies scopes Y and Z, you need to have authorized with 
scopes Y or Z or both, unless the method optionally does not require 
authorization (but discovery doesn't tell you if it does or not), in which 
case, it doesn't matter. Not terribly useful, because the client just doesn't 
have enough information to either send the request through without 
authorization or deliver a useful client-side error.

I think for now, the right answer is to expand the current error message and 
make it easier to understand what's happened, and leave ultimate control of 
this to the developer. But in the long-run, you're right, it would be nice if 
the client could be smart enough to just figure out what you meant.

Original comment by bobaman@google.com on 10 Jan 2012 at 7:00

[GoogleCodeExporter]

Original comment by bobaman@google.com on 10 Jan 2012 at 7:01

• Changed state: On-Hold

[GoogleCodeExporter]

Original comment by bobaman@google.com on 10 Jan 2012 at 7:47

• Added labels: Milestone-Release-1.0

[GoogleCodeExporter]

I think you conflate two very different things.

a) A method may *require* an access token — e.g. a call to an endpoint that 
*only* works with elevated permissions, like (say) posting for someone. These 
validly should give a client-side error without attempt. (Even here, I think 
"missing access token" isn't nearly as clear as it could be — it's rather 
cryptic.)

b) A method may *benefit* from an access token — e.g. G+ list posts gives 
only public responses unless elevated, and may not give any at all for some 
things (i.e. results in a 403 error, though G+ lies and calls it 404). This 
can't be determined without asking the server. The appropriate response here is 
to *try* to do it with current permissions, and in the result, say what level 
of authentication it was using and what results were (e.g. public data only, 
access token with adequate rights, access token with inadequate rights, invalid 
token).

Not everything needs to have OAuth; scrapers for instance don't and in some 
cases even probably *shouldn't* be implicitly encouraged to. Least permissions 
principle of security and all that.

One could throw a *warning* that the call is being made unauthenticated because 
the oauth access token is missing, but it shouldn't be an *error*, and the 
warning should include an instruction for how to suppress it.

Original comment by sai...@gmail.com on 12 Jan 2012 at 8:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Uhm, actually, that's exactly what I was saying, except that I was trying to 
point out that we don't currently have enough information to distinguish 
between a) and b). Hence the requirement that this be controlled by the 
developer.

Original comment by bobaman@google.com on 12 Jan 2012 at 10:31