Trick and Tips

Does your application need end user permission to access their Google data?

When developing web applications, developers are sometimes faced with deciding between AuthSub or OAuth. However, the first question should be, "Who will be granting permission to the users Google data?" If the end users are Google Apps users then most likely it will be an administrator granting access. Frequently developers ask the same question in another way, "Should I use 3-legged or 2-legged authentication?" Ideally, from a Google Apps user experience perspective, it is better to use 2-legged OAuth. This way the application is granted access to a users Google Apps data at the administrator level. The end user can start to use the application and the trust has already been established by an administrator. If you are developing a Marketplace application then it is very likely you will not need to engage in the 3-legged authentication dance.
However, if you are writing an application that is wide open to anyone with a Google account, let the 3-legged dance begin. Both AuthSub and OAuth for Web Applications are designed for this purpose. However, the behavior and look and feel for each is slightly different. Both ultimately allow the user to grant your application access to their data, but knowing the differences helps you make the best choice. Here is an article that covers the topic and should help you choose. It has color coded highlights that compare the two.

Some general rules follow when choosing an authentication method:

End User	Authentication
Google User (regular)	AuthSub or 3-Legged OAuth (3LO)
Googe Apps User (hosted)	2-Legged OAuth (2LO)
No end user	2LO or ClientLogin

Gadgets

Again there are different options for choosing Google Data authentication from a Gadget container. The first option to consider is OAuth Proxy for Gadgets. OAuth proxy is a 3-legged dance asking the end user for permission to access their data. Once access has been granted then the gadget developer can use the gadgets.io.makeRequest()method to make the Google Data API calls. Most likely you will want the JSON response from the feed so remember to add the ?alt=json URL parameter. For more information and code examples on OAuth Proxy see Writing OAuth Gadgets.

For Marketplace Gadgets another authentication option is available and uses OpenID. This option is used to authenticate the user and determine identity only and it does not provide authorization for API access. After the user is authenticated, server-to-server calls are used to make the requests, authorized via 2-legged OAuth and specifying the xoauth_requestor_id based on the authenticated user from OpenID. For more information on this approach see the Marketplace Best Practices page.

Secure Storage of Credentials

Adding layers of security is a common approach to to making data more secure. Google does provide various layers by providing different authentication and authorization methods. Registering web applications, supporting digital certificates, support for industry standards, (SAML, OAuth, OpenID) all help in providing security. However, one of the most common mistakes we can make is not taking care to protect important credentials. When working with Google Data ClientLogin and 2-legged OAuth, these credentials can be keys to the kingdom (e.g. administrator credentials or domain OAuth consumer secret) and therefore should be protected at all costs. Access to these credentials can potentially open the entire Google Apps domain data for the authorized services. This could have tremendous impact especially if you are maintaining 2-legged OAuth credentials for domains that have granted your application access, e.g. a Marketplace application. Therefore it is risky practice to embed them in source code or even a configuration file. Consider using an approach that allows you to enter credentials at runtime and store in memory or use your favorite method for secure storage of these important credentials.

Google Apps Marketplace

With the March announcement of the Google Apps Marketplace, the decision making process may have become a little easier. OpenID+OAuth and 2-Legged OAuth are the schemes that are supported and likely will be used if your Marketplace application needs access to Google Apps data; which is very likely. You’ll notice that the Marketplace has embraced the open standards of OpenID and OAuth. While AuthSub and ClientLogin are proprietary to Google, they will likely not be useful in your Marketplace application.

ClientLogin

If your application needs to create or make modifications to user accounts (using the Provisioning API) then your only current option is ClientLogin. But a common oversight is to not reuse the access token. Without proper reuse of this token, eventually your application will force the account into a CAPTCHA state which can easily be avoided if the access token is used for subsequent ClientLogin authentication requests. It is best to keep this token cached in memory and renew the token in some configured frequency/timeout.

Summary

This post covered some important considerations for selecting a Google Data authentication method for your application. If you are new to Google Data authentications and want to have a better overall understanding then start with the Getting Started with Account Authorization guide. No matter which approach you choose make sure that accessing users data is done is a secure user friendly way.

References

Google Data authentication is a vast topic. For your convenience here are a list of resources.

In this tutorial I’m going to illustrate very basic and simple coding example targeting beginners to use Support Vector Machine (SVM) Implementation in OpenCV for Linearly Separable Data sets. I’m not going to explain the complex mathematical background of finding the optimal hyperplane. However in the first section of the post I’m going to give a simple introduction about support vector machines. 

When we consider classification and machine learning methods SVM is one of simple and easy to use classification method. Regarding image processing there are number of uses of SVM. Image classification and hand written character recognition are some uses of SVM. SVM can be easily used to classify feature vectors extracted from images. 

SVM is a supervised learning method. It defines separating hyperplanes between labeled data sets. These hyper planes can be used to categorize new data set which we don’t know the class label. 

To understand the problem easily instead of hyperplanes and vectors in a high dimensional space I used lines and points in the Cartesian plane (See the below figure).

Here the problem is to select a one from all possible lines which can be used to separate two classes, After defining such hyperplane we can categories new sample data to a class using that separating hyperplane, but it is difficult to define an optimal hyperplane. Based on a criterion we can estimate the worth of the lines. The operation of the SVM algorithm is based on finding the hyperplane that gives the optimal separating hyperplane (largest minimum distance to the training examples). 

In this section I’m going to illustrate how we can use the SVM implementation in OpenCV to classify very simple data set. The SVM implementation in OpenCV is based on LibSVM.

In this example, to train the SVM I used 10 points (x and y coordinates lying on a Cartesian plane). I separate these points in to two classes named as 0 and 1 (See following table).

 

Table 1

float trainingData[10][2] = { { 100, 10 }, { 150, 10 }, { 600, 200 }, { 600, 10}, { 10, 100 }, { 455, 10 }, { 345, 255 }, { 10, 501 }, { 401, 255 }, { 30, 150 } };

float labels[10] = { 0.0, 0.0, 1.0, 1.0, 0.0, 1.0, 1.0, 1.0, 1.0, 0.0 };

#include <opencvcv.h>
#include <opencvhighgui.h>
#include "opencv2/ml/ml.hpp"

void main(){
 float labels[10] = { 0.0, 0.0, 1.0, 1.0, 0.0, 1.0, 1.0, 1.0, 1.0, 0.0 };
 cv::Mat lablesMat(10, 1, CV_32FC1, labels);

 float trainingData[10][2] = { { 100, 10 }, { 150, 10 }, { 600, 200 }, { 600, 10 }, { 10, 100 }, { 455, 10 }, { 345, 255 }, { 10, 501 }, { 401, 255 }, { 30, 150 } };

 cv::Mat trainDataMat(10, 2, CV_32FC1, trainingData);

 //Define parameters for SVM
 CvSVMParams params;
 //SVM type is defined as n-class classification n>=2, allows imperfect separation of classes
 params.svm_type = CvSVM::C_SVC;
 // No mapping is done, linear discrimination (or regression) is done in the original feature space.
 params.kernel_type = CvSVM::LINEAR;
 //Define the termination criterion for SVM algorithm.
 //Here stop the algorithm after the achieved algorithm-dependent accuracy becomes lower than epsilon
 //or run for maximum 100 iterations
 params.term_crit = cvTermCriteria(CV_TERMCRIT_ITER, 100, 1e-6);

 CvSVM svm;
 //Call train function
 svm.train(trainDataMat, lablesMat, cv::Mat(), cv::Mat(), params);

 //Create test features
 float testData[2] = { 150, 15 };

 cv::Mat testDataMat(2, 1, CV_32FC1, testData);

 //Predict the class labele for test data sample
 float predictLable = svm.predict(testDataMat);

 std::cout << "Predicted label :" << predictLable << "
";

 system("PAUSE");

}

#include <opencvcv.h>
#include <opencvhighgui.h>
#include "opencv2/ml/ml.hpp"

void main(){
 int width = 650, height = 650;
 //Create a mat object
 cv::Mat image = cv::Mat::zeros(height, width, CV_8UC3);

 // Set up training data
 float labels[10] = { 0.0, 0.0, 1.0, 1.0, 0.0, 1.0, 1.0, 1.0, 1.0, 0.0 }; //
 cv::Mat labelsMat(10, 1, CV_32FC1, labels);
 float trainingData[10][2] = { { 100, 10 }, { 150, 10 }, { 600, 200 }, { 600, 10 }, { 10, 100 }, { 455, 10 }, { 345, 255 }, { 10, 501 }, { 401, 255 }, { 30, 150 } };//
 cv::Mat trainingDataMat(10, 2, CV_32FC1, trainingData);

 // Define up SVMs parameters
 CvSVMParams params;
 params.svm_type = CvSVM::C_SVC;
 params.kernel_type = CvSVM::LINEAR;
 params.term_crit = cvTermCriteria(CV_TERMCRIT_ITER, 100, 1e-6);

 // Train the SVM
 CvSVM SVM;
 SVM.train(trainingDataMat, labelsMat, cv::Mat(), cv::Mat(), params);

 cv::Vec3b green(0, 255, 0), blue(255, 0, 0);
 // Show the decision regions given by the SVM
 for (int i = 0; i < image.rows; ++i)
 for (int j = 0; j < image.cols; ++j)
 {
  cv::Mat sampleMat = (cv::Mat_<float>(1, 2) << j, i);
  float response = SVM.predict(sampleMat);

  if (response == 1)
   image.at<cv::Vec3b>(i, j) = green;
  else if (response == 0)
   image.at<cv::Vec3b>(i, j) = blue;

 }

 // Show the training data
 int thickness = -1;
 int lineType = 8;
 circle(image, cv::Point(100, 10), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(150, 10), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(600, 200), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(600, 10), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(10, 100), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(455, 10), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(345, 255), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(10, 501), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(401, 255), 5, cv::Scalar(255, 255, 255), thickness, lineType);
 circle(image, cv::Point(30, 150), 5, cv::Scalar(255, 255, 255), thickness, lineType);

 //Show the test data
 circle(image, cv::Point(400, 200), 5, cv::Scalar(0, 0, 255), thickness, lineType);

 imwrite("result.png", image);        // save the image

 imshow("SVM Simple Example", image); // show it to the user
 cv::waitKey(0);

}