MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you:
By Justin Smith, Senior Product Manager

UPDATE 11/14: After considering the feedback and timing, we have decided to delay the launch of the changes described in this post. The new date for these changes is December 7th, 2011. Once again, we expect these changes to have minimal impact. If you have any questions or comments, please post on the OAuth 2.0 Group. We will be actively monitoring that group and will work to respond quickly.


Original post:

In the coming weeks we will be making three changes to the experimental OAuth 2.0 endpoint. We expect the impact to be minimal, and we’re emailing developers who are most likely to be affected.

We will be releasing these changes on December 7, 2011. This post describes the changes, their impact, and how they can be mitigated.

Change #1: Error responses for client-side web applications

The first change relates to the way errors are returned in OAuth 2.0 client-side web applications. It does not impact server-side, native, or device flows.

The current behavior of the OAuth 2.0 endpoint in certain error conditions is to return the error to the application as a query string parameter, for example:

https://www.example.com/back?error=access_denied.

The OAuth 2.0 specification indicates that the error should be returned in the fragment of the response. We are updating our OAuth 2.0 implementation to support the most recent draft of the specification. As a result, we will be changing the way we return errors to applications in the client-side flow.

As an example, today an error returns to your application as

https://www.example.com/back?error=access_denied. After this change, it will be returned as

https://www.example.com/back#error=access_denied.

There is no mitigation for this change, so your application will have to handle these types of errors in client-side script.

Change #2: Offline access as a separate parameter

The second change impacts the OAuth 2.0 server-side flow only. It does not impact client-side, native, or device flows. For context, this flow consists of the following steps:

1. Redirect the browser to the Google OAuth 2.0 endpoint.
2. The user will be shown a consent page.
3. If the user consents, parse the authorization code from the query string of the response.
4. Exchange the authorization code for a short-lived access token and a long-lived refresh token.

Once your application has obtained a long-lived refresh token (step 4), it may access a Google API at any time. This means server-side applications do not require the end-user to be present when obtaining new access tokens. We’re calling this type of access offline.

The client-side flow, in contrast, requires the user to be present when obtaining an access token. This type of access is called online.

With this change, we will be exposing online and offline access as a separate parameter that’s available only in the server-side flow.

When your application requests offline access, the consent page shown to a user will reflect that your application requests offline access and your application will receive an access and a refresh token. Once your application has a refresh token, it may obtain a new access token at any time.

When your application requests online access, your application will only receive an access token. No refresh token will be returned. This means that a user must be present in order for your application to obtain a new access token.

If unspecified in the request, online is the default.

A mitigation for this change is described at the end of this post.

Change #3: Server-side auto-approval

This change also impacts the OAuth 2.0 server-side flow only.

In the current implementation of OAuth2, every time your application redirects a user to Google, that user must give explicit consent before an authorization code is given to your application. As a result, sending a user through the flow another time requires them to see the consent screen again. Most applications don’t do this, but rather use the existing server-side flow as it was intended: a one-time association (import contacts, calendar operations, etc.) where the result is a refresh token which may be used to obtain new access tokens.

The behavior is changing to the following:

• Users will only see the consent screen on their first time through the sequence.
• If the application requests offline access, only the first authorization code exchange results in a refresh token.

To put it another way, consent will be auto-approved for returning users unless the user has revoked access. Refresh tokens are not returned for responses that were auto-approved.

The next section describes how to mitigate this change.

Mitigation of offline access (#2) and auto-approval (#3) changes

If you want to keep the existing behavior in your server-side applications, include the approval_prompt=force and access_type=offline parameters in an authorization code request.

For example, if the following is a target URL for obtaining an authorization code today:

https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code

You can maintain the current behavior by changing the target URL to:

https://accounts.google.com/o/oauth2/auth?
client_id=21302922996.apps.googleusercontent.com&
redirect_uri=https://www.example.com/back&
scope=https://www.google.com/m8/feeds/&
response_type=code&
access_type=offline&
approval_prompt=force

You may start including these parameters in authorization code requests today.

Questions?

If you have any questions or comments, please post on the OAuth 2.0 Group (https://groups.google.com/forum/#!forum/OAuth 2.0-dev). We will be actively monitoring that group and will work to respond quickly.


Justin Smith is a Product Manager who works on authentication and authorization technologies at Google. He enjoys woodworking, cycling, country music, and the company of his wife (not necessarily in that order).

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Jason Robbins, Google Code

When we created the issue tracker for Project hosting on Google Code our goal was to keep things simple. We had found that most issue trackers include too many fields and options that aren't applicable to a given issue. As a result, we intentionally did not implement issue relationships like is-blocked-on and is-duplicate-of. For most of the projects that we host, simply adding a comment that mentions the other issue is enough information to get the job done.

Now we host more large projects, and some projects that started small with us have grown large. So, starting today, we are offering a formal 'Blocked on' field. And, when you close an issue as 'Duplicate', you can merge it into the original issue. For more information, take a look at our issue tracker documentation.

For projects that regularly triage issues, you can now pick where to go after you have finished updating an issue.

We hope that these changes help make the issue tracker as easy to use on larger projects as it is for smaller ones.

As always, we look forward to your feedback.2013, By: Seo Master

Seo Master present to you:
By Ju-kay Kwek, Product Manager

(Cross-posted on the Google App Engine Blog and the Google Enterprise Blog.)

Rapidly crunching terabytes of big data can lead to better business decisions, but this has traditionally required tremendous IT investments. Imagine a large online retailer that wants to provide better product recommendations by analyzing website usage and purchase patterns from millions of website visits. Or consider a car manufacturer that wants to maximize its advertising impact by learning how its last global campaign performed across billions of multimedia impressions. Fortune 500 companies struggle to unlock the potential of data, so it’s no surprise that it’s been even harder for smaller businesses.

We developed Google BigQuery Service for large-scale internal data analytics. At Google I/O last year, we opened a preview of the service to a limited number of enterprises and developers. Today we're releasing some big improvements, and putting one of Google's most powerful data analysis systems into the hands of more companies of all sizes.

• We’ve added a graphical user interface for analysts and developers to rapidly explore massive data through a web application.
• We’ve made big improvements for customers accessing the service programmatically through the API. The new REST API lets you run multiple jobs in the background and manage tables and permissions with more granularity.
• Whether you use the BigQuery web application or API, you can now write even more powerful queries with JOIN statements. This lets you run queries across multiple data tables, linked by data that tables have in common.
• It’s also now easy to manage, secure, and share access to your data tables in BigQuery, and export query results to the desktop or to Google Cloud Storage.

Michael J. Franklin, Professor of Computer Science at UC Berkeley, remarked that BigQuery (internally known as Dremel) leverages “thousands of machines to process data at a scale that is simply jaw-dropping given the current state of the art.” We’re looking forward to helping businesses innovate faster by harnessing their own large data sets. BigQuery is available free of charge for now, and we’ll let customers know at least 30 days before the free period ends. We’re bringing on a new batch of pilot customers, so let us know if your business wants to test drive BigQuery Service.


Ju-kay Kwek is a Product Manager for Google BigQuery Service.

Posted by Scott Knaster, Editor

2013, By: Seo Master