Requiring SSL access to v3.0 feeds in the near future

[Eric (Google)]

**If you already access the API v3.0 using SSL or
are using v-2.0, you can stop reading now.**

Sometime in January, v3.0 will no longer support non-ssl access to the
API. That means
you _must_ access the API feeds over HTTPs (https://docs.google.com/
feeds/default/private/full/...).
The 'http version' of the feeds will no longer work. We believe this
will provide greater
security for users.

What you need to change:

1.) Existing AuthSub/OAuth tokens scoped to 'http://docs.google.com/
feeds/' will no longer work
after the switch is made. You will need to remove all tokens for your
users and have them
fetch new ones, scoped to https://docs.google.com/feeds/.

2. ) Change the feed urls your app is using from http://docs.google.com/feeds/...
to
the SSL version: httpS://docs.google.com/feeds/...

Please post if you have an questions regarding this change.

Eric

[Bobby]

I currently get an error when going over the https urls - this is
using the Java client. The AuthSub token that i'm using is scoped to
https.

The following error is returned:
com.google.gdata.util.AuthenticationException: OK
Unknown authorization header

Sounds like it's expecting secure AuthSub.

Bobby

I hope this doesn't mean that secure AuthSub is required

On Nov 20, 1:08 pm, "Eric (Google)" <api.e...@google.com> wrote:
> **If you already access the API v3.0 using SSL or
> are using  v-2.0, you can stop reading now.**
>
> Sometime in January, v3.0 will no longer support non-ssl access to the
> API.  That means
> you _must_ access the API feeds over HTTPs (https://docs.google.com/
> feeds/default/private/full/...).
> The 'http version' of  the feeds will no longer work.  We believe this
> will provide greater
> security for users.
>
> What you need to change:
>
> 1.) Existing AuthSub/OAuth tokens scoped to 'http://docs.google.com/
> feeds/' will no longer work
> after the switch is made.  You will need to remove all tokens for your
> users and have them

> fetch new ones, scoped tohttps://docs.google.com/feeds/.
>
> 2. ) Change the feed urls your app is using fromhttp://docs.google.com/feeds/...

[Bobby]

The problem was on my side, works ok.

Bobby

[hitoshi uchida]

Dear Eric

Are you planning spreadsheet API will be also changed to https ?

On 11月21日, 午前3:08, "Eric (Google)" <api.e...@google.com> wrote:
> **If you already access the API v3.0 using SSL or
> are using  v-2.0, you can stop reading now.**
>
> Sometime in January, v3.0 will no longer support non-ssl access to the
> API.  That means
> you _must_ access the API feeds over HTTPs (https://docs.google.com/
> feeds/default/private/full/...).
> The 'http version' of  the feeds will no longer work.  We believe this
> will provide greater
> security for users.
>
> What you need to change:
>
> 1.) Existing AuthSub/OAuth tokens scoped to 'http://docs.google.com/
> feeds/' will no longer work
> after the switch is made.  You will need to remove all tokens for your
> users and have them

> fetch new ones, scoped tohttps://docs.google.com/feeds/.
>
> 2. ) Change the feed urls your app is using fromhttp://docs.google.com/feeds/...

[Eric Bidelman]

No, this is just for the DocList API.

[michael saunby]

Hi,

I've only just started using the API but can already appreciate how
security is an issue, so welcome this but I have other concerns.

This API is very powerful, perhaps too powerful. My app engine
application does the following -

User registers and AuthSub token obtained

Future access is via email, send a message with subject "LIST
SPREADSHEETS" or similar and get a message back. More usefully it
will allow upload and download as attachments to email messages.

Thanks to the power of the API and the power of App Engine this is all
quite straightforward. What troubles me is that as the developer and
admin of the App Engine application it's for me to decide which, if
any, email address(es) to link to a particular account. My present
intention is to make it very strict and only tie the

[michael saunby]

(apologies for the earlier truncated post)

Hi,

intention is to make it very strict and only tie the token to the
associated gmail address.

As I'm creating this application for my own use all I need to be sure
of is that my own data is safe, i.e. the service can't be accessed
from other email addresses. If I were to open this service up to
other users for my own peace of mind I'd want to be as sure as I could
be that the tokens I had store on the site could only be used to
receive and send documents to the proper email address. The truth is
though, that once I have the token on my site I could do almost
anything with it.

Initial thoughts are to split the token and send part of it to the
user, so each email request has to provide the missing part of the
token. I'm sure something more sophisticated along these lines would
be useful for other cases.

Something else that might help would be some form of user specified
restrictions, e.g. a token that only gave access to documents with a
specified tag.

But, these worries aside, thanks for a great web service and API.
I'm looking forward to being able to email a document in one language
and getting it emailed back translated to another.

Michael