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

Seo Master present to you: Google has recently added three important enhancements to our OAuth support:

1. The ability to use OAuth without registration
   
2. Support for software apps installed on a computer or mobile phone
3. Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization

Below is an overview of each enhancement, or you can refer to our updated OAuth documentation.

1. The ability to use OAuth without registration

Based on consistent feedback from our developers, we added the ability to use OAuth without having to register the website ahead of time. This change is especially helpful for developers working on test servers that cannot be accessed directly from the Internet.

2. Support for software apps installed on a computer or mobile phone

Many of the larger enterprises that use the Google Apps service choose to run their own login system. They accomplish this by leveraging our support for the SAML protocol which defines a way for Google to redirect the user to the company's login system to be authenticated before accessing their mailbox at Google.  However, in this situation Google normally does not have a password for the user — especially if the enterprise authenticates the user with a password and with a second factor of authentication (such as a token generator they carry on a keychain). Unfortunately, there are many installed software applications created by both Google and ISV developers that use Google's APIs, and those applications are hardcoded to ask a user for their email and password using Google's ClientLogin API. With this new OAuth feature, the software application can now launch a web browser and start a process that both logs the user in through their central SAML login system, and that also gets the user's consent to access their data hosted at Google. Because the user authentication is done in the web browser, it will work with the enterprise's existing login system.  Google is encouraging any ISV that uses the ClientLogin API to add support for this new OAuth flow, enabling usage by the large enterprise customers described above. Google is also planning to enhance our Google Apps Sync for Microsoft Outlook to support this feature such that Outlook can be used with both Google Apps and an enterprise's central login system.

3. Additional controls for our Google Apps Premier and Education customers which allows administrators to give another web application access to a subset of the data Google stores for that organization

This feature for our Google Apps Premier customers enhances our existing OAuth for Google Apps domain administrators, also known as 2-legged OAuth. This feature enables domain administrators to allow specific IT apps or third party web services limited access to user accounts via a centralized permissions system under the control of the  domain administrator. For example, with this new system, an administrator can use the Google Documents API to configure every user in the domain to have a Google Docs folder named "Human Resources" that is automatically populated with common employee forms.  The company might also sign up with an Enterprise SaaS vendor such as Manymoon and specify that Manymoon can access the Google Calendars of all of their users, providing tighter integration with Manymoon's project scheduling features. Previously, this feature required giving the third party vendor access to all of the data that Google stored for that organization, but with this new feature, administrators can limit access to particular data sources (Calendar, Documents, etc). Refer to our documentation for more information.

By Eric Sachs, Product Manager, Google Security2013, By: Seo Master

Seo Master present to you: Do you operate a website and wish you could increase the percentage of users who finish the registration process? As discussed on Google's main blog, Google has been working with Plaxo and Facebook to improve the registration success rate for Gmail users. We now see success rates as high as 90%, compared to the 50-60% rate that most websites see with traditional registration mechanisms. This result was achieved using a combination of our OpenID, OAuth and Portable Contacts APIs. While those APIs have been available for over a year, we have added a number of refinements based on our experience with Plaxo and Facebook. Our documentation now has information on those new features, including:

• OpenID User Interface Extension 1.0 (including the ability to display the favicon of the website)
• x-has-session, which is an enhacement to checkid_immediate requests via the UI extension. If the request includes "openid.ui.x-has-session," it will be echoed in the response only if Google detects an authenticated session
• Support for the US Government's GSA profile for OpenID
• PAPE (Provider Authentication Policy Extension) to support forced password reprompts
• Support for not only Google Accounts, but also our Google Apps customers, as discussed on the Enterprise blog

For more details, please refer to our OpenID documentation.

While these technologies are all standards-based, the methods for how to combine them to achieve this success rate are not obvious, and took a while for the industry to refine. More information is available in the Hybrid Onboarding Guide, but below is a quick summary of some of the best practices for this hybrid onboarding technique:

• The technique is primarily for websites with an existing login system based on email addresses.
• It also assumes the website will send email to users who are not yet registered, whether it is through traditional email marketing or social network invitations.
• The website owner then needs to choose a small set of email providers such as Yahoo and Google that support these standards.
• Whenever the website sends email to a user at one of those providers, any hyperlinks that promote registration at the website should be modified to communicate the email address (or at least domain) of the user back to the website's registration page.
• If the registration page detects a user from one of these domains, it should NOT start the traditional process of asking the user to enter a password, password confirmation, and email. Instead, it should prominently show a single button that says "Sign up with your Google Account" — where Google is replaced with the name of the email provider.
• If the user clicks that button, the website should use the OpenID protocol to ask the email provider to authenticate the user, provide their email address, and optionally ask for access to their address book using the hybrid OpenID/OAuth protocol and the Portable Contacts API. More details about this flow are available on the OpenID blog.
• Once the user returns to the website, it can create an account entry for the user. The website can also mark the email address as verified without having to send a traditional "email verification" link to the user. If the website received the user's permission to access their address book, it can now download it and look for information about the user's friends.
• In the unusual case where an account already exists for that email address, the website can simply log the user into that pre-existing account. 
• For any newly registered user, the website should then display a page that confirms the user is registered and that indicates how they should sign in in the future.
• To make the login process simple, the website should modify their login box to include a logo for each of the trusted email providers it supports, or use one of the other user experiences for Federated Login.
• If a user clicks the email provider button, they can again be sent to that provider's site using the OpenID protocol. When the user comes back, the website can either detect that they previously registered, or if it is a new user, the website can create an account for them on the fly.
• In some cases the account may already exist for that email address, but it was not initially registered using OpenID. In that case, the website can simply log the user in to that pre-existing account.

By Eric Sachs, Product Manager, Google Security2013, By: Seo Master

Seo Master present to you:

Last year, as part of Google’s initiative to make the web faster, we introduced Page Speed, a tool that gives developers suggestions to speed up web pages. It’s usually pretty straightforward for developers and webmasters to implement these suggestions by updating their web server configuration, HTML, JavaScript, CSS and images. But we thought we could make it even easier -- ideally these optimizations should happen with minimal developer and webmaster effort.

So today, we’re introducing a module for the Apache HTTP Server called mod_pagespeed to perform many speed optimizations automatically. We’re starting with more than 15 on-the-fly optimizations that address various aspects of web performance, including optimizing caching, minimizing client-server round trips and minimizing payload size. We’ve seen mod_pagespeed reduce page load times by up to 50% (an average across a rough sample of sites we tried) -- in other words, essentially speeding up websites by about 2x, and sometimes even faster.

(Video comparison of the AdSense blog site with and without mod_pagespeed)

Here are a few simple optimizations that are a pain to do manually, but that mod_pagespeed excels at:

• Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
• Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
• Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

We’re working with Go Daddy to get mod_pagespeed running for many of its 8.5 million customers. Warren Adelman, President and COO of Go Daddy, says:

"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”

We’re also working with Cotendo to integrate the core engine of mod_pagespeed as part of their Content Delivery Network (CDN) service.

mod_pagespeed integrates as a module for the Apache HTTP Server, and we’ve released it as open-source for Apache for many Linux distributions. Download mod_pagespeed for your platform and let us know what you think on the project’s mailing list. We hope to work with the hosting, developer and webmaster community to improve mod_pagespeed and make the web faster.

By Richard Rabbat, ‘Make the Web Faster’ initiative2013, By: Seo Master