I seem to have stumbled upon this link https://developers.google.com/gdata/faq#AuthScopes which gives the AuthSub/Oauth 1 scope as http://picasaweb.google.com/data/

However, the OAuth 2 scope is https://picasaweb.google.com/data/ as given in https://developers.google.com/picasa-web/docs/2.0/developers_guide_protocol#Auth

(In reply to comment #1)
> I seem to have stumbled upon this link
> https://developers.google.com/gdata/faq#AuthScopes which gives the
> AuthSub/Oauth 1 scope as http://picasaweb.google.com/data/
> 
> However, the OAuth 2 scope is https://picasaweb.google.com/data/ as given in
> https://developers.google.com/picasa-web/docs/2.0/developers_guide_protocol#Auth

So that could be the problem, but also the problem could be caused by PicasaWeb not being added as an authorisation domain to the GOA object in gdata_goa_authorizer_set_goa_object() in gdata-goa-authorizer.c. Unless you’ve patched libgdata locally to add that?

I can’t remember from our IRC conversation what changes you’ve made locally and what the symptoms are of the failure you’re experiencing. Can you please reiterate what the problem is? Thanks.

(In reply to comment #2)
> So that could be the problem, …

I should probably say: I’m not sure it should be a problem, because Google are generally quite good about accepting both ’http’ and ‘https’ for things like this, and also maintaining backwards compatibility for this kind of identifier. Indeed, I think you said on IRC that changing this URI in the source code didn’t help, which means the bug is elsewhere.

(In reply to comment #2)

> So that could be the problem, but also the problem could be caused by PicasaWeb
> not being added as an authorisation domain to the GOA object in
> gdata_goa_authorizer_set_goa_object() in gdata-goa-authorizer.c. Unless you’ve
> patched libgdata locally to add that?

Thanks for looking into this, Philip. The original problem was solved after modifying gdata_goa_authorizer_set_goa_object() to add authorization domains for Photos. 

However, now I am up against something else. Even, though the service is authorized now, gdata_picasaweb_service_query_all_albums () gives a 
"Authentication required: Authorization required" error. I am trying to find out what is the cause behind it.

Created attachment 278668 [details] [review]
My local changes

I have attached what local changes I have made and am mentioning a few things to better describe the problem.

Earlier the PicasaWebService I created wasn't actually authorized when checked using gdata_service_is_authorized (). But after the changes I made, it is authorized. However, when using gdata_picasaweb_service_query_all_albums () now, I am getting 'Authentication required: Authorization required' error. 

I have been going through the libgdata code to see if I missed adding anything more but haven't found anything so far.

Also, in case it helps, I added support for PicasaWeb to GNOME Online Accounts in Bug 728877.

Created attachment 278701 [details] [review]
core: Add PicasaWeb support to GDataGoaAuthorizer

GOA has supported photos for a long time. Grab PicasaWeb
authentication if GOA has already got a token supporting it.

This bumps the GOA dependency to 3.8.

Comment on attachment 278701 [details] [review]
core: Add PicasaWeb support to GDataGoaAuthorizer

I have committed your patch, since it is a useful bug fix. I'll take a look at the remaining problems later.

Attachment 278701 [details] pushed as 2e9da05 - core: Add PicasaWeb support to GDataGoaAuthorizer

(In reply to comment #5)
> Created an attachment (id=278668) [details] [review]
> My local changes
> 
> I have attached what local changes I have made and am mentioning a few things
> to better describe the problem.
> 
> Earlier the PicasaWebService I created wasn't actually authorized when checked
> using gdata_service_is_authorized (). But after the changes I made, it is
> authorized. However, when using gdata_picasaweb_service_query_all_albums ()
> now, I am getting 'Authentication required: Authorization required' error. 

The only thing that comes to mind is that the authorisation domain URI used in GOA (‘https://picasaweb.google.com/data/’) doesn’t match that used in libgdata (‘http://picasaweb.google.com/data/’) as you noted before. You could try changing this (line 126 of gdata-picasaweb-service.c), but I don’t think it will fix things.

If you could show me the code of your program, plus get a log of it running, I should be able to debug further. Please run your program with these environment variables set:
    G_MESSAGES_DEBUG=all LIBGDATA_DEBUG=3

Thanks.

Created attachment 278732 [details]
Log for Photos

Created attachment 278733 [details]
Log for Documents

I have attached logs for both cases - when I try to index Documents (which seems to run well) and when I try to index PicasaWeb Photos (for which I am getting an error).

The code which I have added/modified can be seen over my github repo at 
https://github.com/saurav-agarwalla/gnome-online-miners/blob/wip-picasaweb/src/gom-gdata-miner.c

(In reply to comment #8)

> The only thing that comes to mind is that the authorisation domain URI used in
> GOA (‘https://picasaweb.google.com/data/’) doesn’t match that used in libgdata
> (‘http://picasaweb.google.com/data/’) as you noted before. You could try
> changing this (line 126 of gdata-picasaweb-service.c), but I don’t think it
> will fix things.

I have tried changing it but, as you mentioned, it doesn't fix things.

Created attachment 278739 [details] [review]
core: Refresh authoriser on receiving SOUP_STATUS_FORBIDDEN

Previously the authoriser was only refreshed on receiving a
SOUP_STATUS_UNAUTHORIZED response from the server. This worked fine for
Google Documents, but it seems that PicasaWeb returns FORBIDDEN instead.
The authoriser was not being refreshed, and hence the user was seeing
access denied messages even though they were technically logged in.

Looking at the logs, it seems that PicasaWeb returns a HTTP 403 where Documents returns a HTTP 401. The latter triggered the authoriser to refresh its authorisation, whereas the former didn’t — and hence failed.

Thanks for your help in debugging this, Saurav!

Attachment 278739 [details] pushed as 109417f - core: Refresh authoriser on receiving SOUP_STATUS_FORBIDDEN