Hello friends,It was asked in a previous thread if we could provide OAuth capabilities for accessing Reader data. We recently enabled OAuth support for Reader. You can find relevant information here: http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html
To unsubscribe from this group, send email to fougrapi+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
It will work for reader/atom/* . It doesn't however work for subscriptions/export . If this is a problem I can see about getting it added.
Do I need to expand the "scope" while asking for OAuth tokens? if it's possible that is.
I am making a request to http://www.google.com/reader/api/0/edit-tag
It is strange, because before calling this I need to get token from
http://www.google.com/reader/api/0/token which I get successfully.
Are you sure you have enabled OAuth on edit-tag requests?
Thanks.
--
Jayesh
I think I have tested all the endpoints so far and except for the two
all others are working.
The failing ones are edit-tags and subscriptions/export.
Calls on http://www.google.com/reader/api/0/edit-tag fail with 401 Unauthorized
Calls on http://www.google.com/reader/subscriptions/export fail with
some unknown error. I get HTTP response code -1.
Please let me know if you find something wrong about these end points
on google reader side.
--
Jayesh
Thanks.
--
Jayesh
The POST requests to "api/0/stream/items/contents" are successful.
But POST requests to "api/0/item/edit", "api/0/mark-all-as-read",
"api/0/edit-tag" fail.
--
Jayesh
On Wed, Mar 31, 2010 at 8:29 AM, Mihai Parparita <mih...@google.com> wrote:
> Are you providing the T action token? That's still required even with OAuth.
Yes I am doing that. My code is unchanged except for OAuth signing at
lower level, so I am adding POST params just like before, including
the Token.
Could you tell me which client library did you use to test (if it is
publicly available)? I can recheck my code against it.
I am using SignPost, which apparently seems to be a standard OAuth
library, but I will check.
I tried all I could think of, but no help.
I analysed the java SignPost library I was using and dumped the post
params/ signature base string etc. But couldn't find anything useful.
I also tried couple of python libraries to get more sample points, but
couldn't get those libraries beyond getRequestToken. They all are well
tested for Twitter, but can't seem to handle the "scope" post param
required for Google oauth.
IIRC, you guys can lookup the requests in server logs based on User
Agent strings. Do you think you can tell me if you find something
there? I ran the test that marks an item read about 5-10 min ago, with
the SOURCE http header set to "ReaderScope 1.8.5x". I got
401-Unauthorized for an edit-tag method invocation. Can Google Reader
log tell what in particular went wrong in that request? There should
be only one request with that SOURCE field, so it should be easily
searchable provided it is kept in logs.
It's difficult at the client side, because there are many things that
can go wrong in signing the OAuth request properly. It doesn't help
that server returns same error code for all of those errors (401).
Let me know if you can help or have any more suggestions.
Thanks.
--
Jayesh
On Fri, Apr 2, 2010 at 1:58 AM, Brad Hawkes <bha...@google.com> wrote:
> Hi Jayesh,
> I looked up your request and it was indeed an error due to an invalid
> signature.
> I think the problem you are having is a known issue with SignPost.
> From http://code.google.com/p/oauth-signpost/wiki/GettingStarted :
> When using HttpURLConnection, you cannot sign POST requests that carry query
> parameters in the message payload (i.e. requests of type
> application/x-www-form-urlencoded). This is not a limitation of Signpost per
> se, but with the way URLConnection works. Server communication with
> URLConnection is based on data streams, which means that whenever you write
> something to the connection, it will be sent to the server immediately. This
> data is not buffered, and there is simply no way for Signpost to inspect
> that data and include it in a signature. Hence, when you have to sign
> requests which contain parameters in their body, you have to use an HTTP
> library like Apache Commons HttpComponents and the respective Signpost
> module. (This restriction does not apply to requests which send binary data
> such as documents or files, because that data won't become part of the
> signature anyway.)
> -Brad
Thanks a bunch Brad. That seems to explain it. I will try the
suggestions later today and report what I find.
Authentication error: Unable to respond to any of these challenges:
{oauth=WWW-Authenticate: OAuth
realm="https://www.google.com/accounts/OAuthGetRequestToken",
service="reader"}
I am not sure why the error talks about GetRequestToken. I already
have access token and secret, which work perfect for other queries.
I also tried to expand the scope by adding
www.google.com/reader/subscriptions to it, but that gives an error.
Any idea?
--
Jayesh
The exact request-response details are:
Request:
------------
GET http://www.google.com/reader/subscriptions/export HTTP/1.1
Authorization : OAuth
oauth_token="1%2FQFKEFjVe0KE8mrPy6zpJA2ty9VceETm-b9xJXKiyMoM",
oauth_consumer_key="<myconsumerkey>", oauth_version="1.0",
oauth_signature_method="HMAC-SHA1", oauth_timestamp="1270356512",
oauth_nonce="2173450765791751214",
oauth_signature="8lQAxDhVrA0JQ%2FXbe92Gu2hOdbI%3D"
Response:
--------------
HTTP/1.1 401 Unauthorized
Content-Type : text/html; charset=UTF-8
WWW-Authenticate : OAuth
realm="https://www.google.com/accounts/OAuthGetRequestToken",
service="reader"
Date : Sun, 04 Apr 2010 04:44:50 GMT
Expires : Sun, 04 Apr 2010 04:44:50 GMT
Cache-Control : private, max-age=0
X-Content-Type-Options : nosniff
X-Frame-Options : SAMEORIGIN
X-XSS-Protection : 1; mode=block
Content-Length : 1334
Server : GSE
Now I am making other GET requests which are returning success. So I
dumped their request headers and verified that they look the same as
the above request.
I looked into the following RFC about the 401 response generated by
the server and the meaning of "WWW-authenticate: OAuth realm"
http://tools.ietf.org/html/rfc2617#section-1.2
As I understand it from the RFC, the server is challenging the client
to provide OAuth credentials. But as you see, I am providing them in
the request. So my best guess on this is that even though OAuth might
be enabled on subscriptions/export, it does not fall into the same
space as other requests. That is why it is in a way prompting the
client to do OAuth authentication by suggesting the
OAuthGetRequestToken URL (first step in OAuth authentication process).
Does this make sense?
Please let me know. Thanks.
--
Jayesh
Can you include the full HTTP request response where you get 401s or
403s (including other headers and the status string, which may contain
more information like "401 Token expired")?
Mihai
Are you sure your authorization went through fine? Also I've gotten
the 401 error when I requested access using a scope of https and tried
to run a query through http, so that is something to double check.
Usually a 401 error means your