Google’s URL Shortener has been used by Google services like FeedBurner, Google News, Blogger to share links on Twitter. Google didn’t provide a web interface for the service, but third-party sites managed to fill the void.

Now you can go to goo.gl, paste any web address and get a short URL. Google also shows stats for any short URL generated using the service: append “.info” to the address and you’ll see the number of clicks, a list of traffic sources and some aggregate information about visitors.

So where do you start? well if you don’t have a google account signup now and then get an API Key.

If you sign in to a Google account, Google will save a list of recently generated URLs. Another advantage is that Google will always generate unique URLs when you are logged in, so that the stats are more useful.

Now that you have your google account and API Key we need to create some PHP code that will grab our short url and display it. First, I’ll walk you through on how it’s done, then I’ll give the full script at the end. Let’s start off with what we need, and that is, the URL that you want to shorten.

$url = 'http://benzingtech.com/fort-myers-web-design/';

If you want to associate the shortened urls to your Google account, just put it your email address and password. You can also add in a Google API key if you have one. Remember, these values are optional.

$email    = ''; // OPTIONAL: GMail or Google Apps email address
$password = ''; // OPTIONAL: Your Password for above account
$api_key  = ''; // Required

Next thing we do is use Google’s ClientLogin API to get an Auth key for us to authenticate our requests later. Notice the POST parameters that we include in the request, as required by the API. See the ClientLogin documentation to view other details. For this example I used the Sudocode xhttp class to fetch my results.

if($email and $password) {
   $data = array();
   $data['post'] = array(
      'accountType' => 'HOSTED_OR_GOOGLE',
      'Email'       => $email,
      'Passwd'      => $password,
      'service'     => 'urlshortener',
      'source'      => 'benzingtech-example-v1' // Application's name, e.g. companyName-applicationName-versionID
      );
 
   $response = xhttp::fetch('https://www.google.com/accounts/ClientLogin', $data);

One IMPORTANT note is the service parameter, “urlshortener”, which is undocumented.

If the request was successful, it will return three lines of text; one for each key: SID, LSID and Auth.

SID=DQAAAGgA...7Zg8CTN
LSID=DQAAAGsA...lk8BBbG
Auth=DQAAAGgA...dk3fA5N

The lines are way much longer than the example above. If not successful, refer to the documention for the error codes you might get when trying to login. We just need the Auth key for our script and we use PHP’s function preg_match to extract it.

preg_match('/Auth=(.+)/', $response['body'], $matches);
$auth = $matches[1];

Here is why I said earlier that I don’t advise using the code as-is, the Auth key can be cached for a long time, as long as you use it regularly. Be sure to cache your Auth Key between sequential requests to minimize URL fetches thus making your app faster and use less processes.

Now that we got our Auth key, and URL to shorten finally, we ask goo.gl to shorten our long URL. We pass off the Auth key in the Authorization header.

if(isset($auth)) $data['headers']['Authorization'] = "GoogleLogin auth=$auth";
if($api_key) $data['get']['key'] = $api_key;

We set the correct Content-Type (application/json), as expected by the API. My xhttp class takes care of converting the array to a JSON string.

$data['headers']['Content-Type'] = "application/json";
$data['post'] = array(
   'longUrl' => $url,
   );
$response = xhttp::fetch("https://www.googleapis.com/urlshortener/v1/url", $data);

Congrats you are Done. We could retrieve the short url by decoding the response and getting the id field like so:

$var = json_decode($response['body'], true);
$shortURL = $var['id'];
echo $shortURL;

Note: that a new URL is generated for each request even if you shorten the same long URL if you do not use the API Key

<?php
 
$url = 'http://benzingtech.com/fort-myers-web-design/';
 
$email    = ''; // OPTIONAL: GMail or Google Apps email address
$password = ''; // OPTIONAL: Your Password for above account
$api_key  = ''; // Required
 
require 'class.xhttp.php';
 
if($email and $password) {
   $data = array();
   $data['post'] = array(
      'accountType' => 'HOSTED_OR_GOOGLE',
      'Email'       => $email,
      'Passwd'      => $password,
      'service'     => 'urlshortener',
      'source'      => 'benzingtech-example-v1' // Application's name, e.g. companyName-applicationName-versionID
      );
 
   $response = xhttp::fetch('https://www.google.com/accounts/ClientLogin', $data);
 
   // Check if login failed
   if(!$response['successful']) {
      echo "Login Failed\n";
      print_r($response);
      die();
   }
 
   preg_match('/Auth=(.+)/', $response['body'], $matches);
   $auth = $matches[1];
}
 
$data = array();
if(isset($auth)) $data['headers']['Authorization'] = "GoogleLogin auth=$auth";
if($api_key) $data['get']['key'] = $api_key;
 
$data['headers']['Content-Type'] = "application/json";
$data['post'] = array(
   'longUrl' => $url,
   );
 
$response = xhttp::fetch("https://www.googleapis.com/urlshortener/v1/url", $data);
 
if($response['successful']) {
   $var = json_decode($response['body'], true);
   $shortURL = $var['id'];
   echo $shortURL;
 
} else {
   print_r($response);
}
 
?>

Benzing Web Design Marketing

If you are familiar with blogosphere you know what is Technorati.

Technorati is an Internet search engine for searching blogs. You can submit your blog to Technorati and ping their servers when your blog site is updated. when you ping Technorati their web crawlers read the updated information on your site.

Technorati offers an XML-RPC ping web service to allow blogs to notify content changes.

In this article we discuss how to write a PHP script to programatically ping Technorati when there is new content in your site.

The URL to ping is rpc.technorati.com/rpc/ping.

The method name to call is weblogUpdates.ping.

The request XML must contain two parameters – your blog site name the blog site URL.

From the API documentation of Technorati, the sample request XML is as below:

<?xml version="1.0"?>
  weblogUpdates.ping
  YOUR WEBLOG NAME HERE
  http://www.YOURWEBLOGURL.com/

Let’s start writing the XML-RPC client to ping Technorati.

Our first step is to generate the required XML request string.

<?php
$site_name = "YOUR WEBLOG NAME HERE";
$site_url = "http://www.YOURWEBLOGURL.com";
 
$request = xmlrpc_encode_request("weblogUpdates.ping", array($site_name, $site_url));
?>

The function xmlrpc_encode_request as the name suggests, creates the request XML string. If you echo $request variable you will see output like below:

<?xml version="1.0" encoding="iso-8859-1"?>
 
weblogUpdates.ping
 
   Benzing Technologies
 
   http://benzingtech.com

The next step is to create the streams context.

<?php
$context = stream_context_create(array('http' => array(
    'method' => "POST",
    'header' => "Content-Type: text/xml\r\nUser-Agent: PHPRPC/1.0\r\nHost: rpc.technorati.com\r\n",
    'content' => $request
)));
?>

The code snippet states that we are preparing to make an HTTP POST request to the server rpc.technorati.com.

The next step is to make the request.

<?php
$server = "http://rpc.technorati.com/rpc/ping";
$file = file_get_contents($server, false, $context);
?>

We now decode the response XML using the function xmlrpc_decode(). We determine whether the response XML contains a fault structure using the xmlrpc_is_fault() function.

<?php
$response = xmlrpc_decode($file);
if (is_array($response) and xmlrpc_is_fault($response)){
    echo "Failed to ping Technorati";
} else {
    echo "Successfully pinged Technorati";
}
?>

The entire script is pasted below.

<?php
$site_name = "Benzing Technologies";
 
/**
 * The URL of your site
 */
$site_url = "http://benzingtech.com";
 
$request = xmlrpc_encode_request("weblogUpdates.ping", array($site_name, $site_url));
 
#echo $request;

$context = stream_context_create(array('http' => array(
    'method' => "POST",
    'header' => "Content-Type: text/xml\r\nUser-Agent: PHPRPC/1.0\r\nHost: rpc.technorati.com\r\n",
    'content' => $request
)));
 
$server = "http://rpc.technorati.com/rpc/ping";
$file = file_get_contents($server, false, $context);
 
$response = xmlrpc_decode($file);
 
if (is_array($response) and xmlrpc_is_fault($response)){
    echo "Failed to ping Technorati";
} else {
    echo "Successfully pinged Technorati";
}
 
?>

The source code is available from the Code Album Github repository.

Benzing Web Design Marketing

Originally Posted at Carsonified.com

Securing cookies and sessions is vital to keeping an application secure. Many tutorials have been written on the subject, but as the internet (and browsers loading it) evolve so do the methods you can use to keep your application secure.

In this article we’re going to break down the various components of a cookie and what they mean for security. This will include limiting the cookie to certain domains and paths on those domains, choosing what information to store, and protecting the cookie from cross site scripting exploits. In a second article we will go into more depth in how to protect everyone’s favorite cookie, the session ID.

How Cookies Work

Cookies are simply key/value pairs that let us get around HTTP being a stateless protocol. When a developer has data they wish to last for more than one connection they can use cookies to store that data on the client side. While this tends to get handled by the programming language being used it is accomplished using HTTP headers.

When the server wants to set a cookie it passes back a header named “Set-Cookie” with the key-value pair and some options.

View larger

On subsequent requests the client will send along its own header to let the server know the name and value of its stored cookies. The server will not continue to send back the cookies, it will only send them if there is a change.

View larger

You can see all the headers for yourself using the LiveHeaders plugin for Firefox.
The Problem

This data is completely in control of the client- it is trivial to change the values of a cookie. That means that, just like post and get data, all cookie data must be validated in some way. At the same time you’ll want to avoid storing sensitive information, such as passwords, as cookies are stored in cleartext and anyone with access to the computer later can easily pick those up (I know of at least one security forum that was hacked in this way). It is also important to note that HTTP does not encrypt the headers in any way. If the connection isn’t over SSL then it will not be protected from snooping eyes.

Session cookies are no different than any other cookie- their value is just a simple ID. Those IDs are susceptible to all of the same limitations as other cookies. The real power behind sessions happens server side, where the ID is used to pull out data stored on the server. This has many benefits over storing data directly into the cookie itself- data can’t be manipulated by the user, large amount of data can be stored without having to send it back and forth with each request, and you can store data you otherwise wouldn’t want the client to have access to.
Getting Started

The first step towards securing your cookie is to restrict that cookie to only your application. This is especially important in environments that support multiple sites or applications (the type of shared hosting you often see on corporate or university domains). By restricting the cookie to only the applications that need it you reduce the chances of it being sniffed while also keeping the cookie namespaces clear for other applications that use them.

There are three options that can be sent along when creating a cookie that, when used properly, will keep the cookie limited to only your application. Before setting these options you will need to ask yourself a few questions-

• What parts of the website need access to the cookie?
• Will the cookie need to work across sub domains?
• Will the cookie need to persist if the user leaves an SSL portion of the site?

There is also a forth option used by newer browsers to restrict access to cookies by javascript.

As you will see, how exactly to restrict the cookie really does depend on the exact purpose for that cookie. A banking or ecommerce site may restrict their cookies to only SSL, while a blog or news aggregator may want to leave things more open.
Cookie Options

Send The Cookie To Only Your Application

The Path argument specifies what paths on the site to send the cookie. The default value of “/” means every request will get the cookie, while “/forums/” would limit the cookie to just that path. This path is going to be based on the actual URL the browser uses, before any mod_rewrite or other URL mapping.

Don’t Share With Sub Domains

The Domain option allows you to specify whether or not to send the cookie to subdomains. Setting “www.example.com” will mean only the exact domain “www.example.com” will be matched, while “.example.com” will also match again any subdomaim (forums.example.com, blog.example.com).

Require a Secure Connection

Using the Secure option you can tell the browser (or other http clients) to only send the cookie over SSL connections. This means the cookie will not be available to any part of the site that is not secure will not have access to the cookie, but it also makes it much less likely that you’ll accidentally send the cookie across as cleartext.

Protect Against XSS Exploits

This HttpOnly flag is used to tell the browser that it should not allow javascript to access the contents of the cookie. This is primarily a defense against cross site scripting, as it will prevent hackers from being able to retrieve and use the session through such an attack.

The HttpOnly option is not by any means full proof. As a client-side defense mechanism it relies on browser support to work, but is only supported by a few browsers (Firefox 3+ and IE 7+, with partial support from Opera 9.5, IE6 and Chrome).

Configuring the Cookie

In PHP, setting the arguments for cookies is done through some optional arguments on the “setcookie” function:

setcookie( name, value, expire, path, domain, secure, httponly);
 
// Open
setcookie( 'UserName', 'Bob', 0, '/', '.example', false, false);
 
// Locked Down
setcookie( 'UserName', 'Bob', 0, '/forums', 'www.example.com', isset($_SERVER["HTTPS"]), true);

To change the cookie values for the session cookie requires the “session_set_cookie_params” function, which needs to be called before the session is started.

session_set_cookie_params($expire, $path, $domain, $secure, true);
 
// Open
session_set_cookie_params(0, '/', '.example', false, false);
 
// Locked Down
session_set_cookie_params('o, /forums', 'www.example.com', isset($_SERVER["HTTPS"]), true)

Summary

Cookies remain the basic method of identify tracking on most websites and keeping them secure is a vital part to keeping applications as a whole locked down and secure. In this article we went over four methods for protecting cookies on a general level.

When using cookies its important to remember to:

• Limit the amount of sensitive information stored in the cookie.
• Limit the subdomains and paths to prevent interception by another application.
• Enforce SSL so the cookie isn’t sent in cleartext.
• Make the cookie HttpOnly so its not accessible to javascript.

Please check out the second half of this series, where we’re going to take the next step with an in depth guide to securing sessions.

Related Blogs

• Related Blogs on cookies
• No brag, just fact: these butter-pecan cookies are DA BOMB. | King …

• Related Blogs on security

Benzing Web Design Marketing