Framebreaker – X-Frame-Options

Mit dem Header X-Frame-Options:DENY wird angezeigt das die Seite nicht in einem iFrame/Frame eingebunden werden darf. Alternativ geht auch die Einstellung: SAMEORIGIN damit zumindest Seiten von der selben Domain die Seite framen dürfen.

Nicht Tracken – DNT

Der DNT (Do Not Track)-Header wird vom Firefox als Anfrage-Header mitgeschickt wenn der Benutzer das konfiguriert hat. Er soll anzeigen das man den User nicht für Werbezwecke verfolgen soll. Laut Blog Artikel sind damit die “Online Behavioral Ads” bzw. Remarketing gemeint.

User Agent kürzer

Der Firefox User Agent Header wurde verkürzt und verrät jetzt weniger. Der UA für Firefox 4 sieht damit zum Beispiel so aus:

Mozilla/5.0 (Windows NT x.y; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

SSL aber fix – Strict-Transport-Security

Der Strict-Transport-Security Header zeigt an das die Seite nur über SSL aufrufbar ist. Dieser Header wird vom Server geschickt und dann im Browser zwischengespeichert. Nach dem ersten Aufruf weiß der Browser also dann immer das die Seite nur verschlüsselt angezeigt werden kann. Man kann den Header auf Subdomains ausweiten und mit einem Timeout versehen:

Strict-Transport-Security: max-age:expireTime [; includeSubdomains]

We need the HTML for the language-chooser and a short javascript …

 
<script> 
 
	$(function(){
		$('#languages a').click(function(evt){
			$('#content').translate($(this).attr('rel'));
			$('#languages a').removeClass('active');
			$(this).addClass('active');
		});
	});
 
</script>
 
<div id="languages">
	<a rel="de" class="active" href="#">Deutsch</a>
	| <a rel="en" href="#">English</a>
	| <a rel="es" href="#">Español</a>
	| <a rel="fr" href="#">Française</a>
</div>

“Signierte Requests”, “Request- und Access-Token” … alles nicht so schlimm wie es sich anhört. Die Zend_Oauth_Consumer Klasse von Zend Framework nimmt einem die meiste Arbeit ab. Am Beispiel von Twitter zeig ich mal schnell wie das geht.

Allgemein
Der grundsätzliche Ablauf ist folgender: Als erstes bei der API einen Request-Token anfordern, mit diesem Token dann den Benutzer auf die Twitter-Seite umleiten (Redirect) und wenn der Benutzer auf “Erlauben” klickt wird man zurück auf die eigene Seite umgeleitet und bekommt einen Access-Token.

Für den ganzen Ablauf muß man sich vorher von Twitter einen consumerKey und consumerSecret abholen, dazu muß die eigene Anwendung, die auf die Twitter API zugreifen will, registriert werden. Das kann man unter folgender URL machen: http://dev.twitter.com/apps/new

 
$config= array(
	'callbackUrl' => 'http://bohuco.net/labs/twitter-backup',
	'siteUrl' => 'http://twitter.com/oauth',
	'consumerKey' => 'ueQgVFLypAzN0vkbiZiyw',
	'consumerSecret' => '9SB9W8J66lPsKyu766bzGpoPN21q0tjJh6JV1Rp8'
);

Request Token anfordern
Der Request Token dient dazu die nachfolgende Anfrage zu signieren und gilt immer nur für einen Request. Man braucht ihn also für den nachfolgenden Redirect auf die Twitter-Authorize Seite. Den Request Token muß man aufheben weil man damit die Antwort von Twitter wieder entschlüsseln muß darum speichern wir ihn in der Session.

	$consumer = new Zend_Oauth_Consumer($config);
	$token = $consumer->getRequestToken();
	$_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token);

Wenn man den Request Token in der Session hinterlegt hat kann man den Benutzer auf die Twitter Seite umleiten und hoffen das er mit einer positiven Antwort zurückkommt …

	$consumer->redirect();

Falls der Benutzer dann wirklich zurückkommt wird mittels Request-Token (aus der Session) und der Antwort von Twitter (die in $_GET steht) der Access-Token erzeugt. Den Access-Token kann man entweder in der Session oder in der Datenbank speichern, er läuft nicht ab und gilt solange bis der Benutzer diese Berechtigung bei Twitter wieder aufhebt.

Den Request-Token kann man vergessen den braucht man jetzt nicht mehr.

	$consumer = new Zend_Oauth_Consumer($config);
	$_SESSION['TWITTER_ACCESS_TOKEN'] = serialize($consumer->getAccessToken($_GET, unserialize($_SESSION['TWITTER_REQUEST_TOKEN'])));
	$_SESSION['TWITTER_REQUEST_TOKEN'] = null;

Der gesamte Quelltext würde dann ca. so aussehen …

 
$config = array(
	'callbackUrl' => 'http://bohuco.net/labs/twitter-backup',
	'siteUrl' => 'http://twitter.com/oauth',
	'consumerKey' => 'ueQgVFLypAzN0vkbiZiyw',
	'consumerSecret' => '9SB9W8J66lPsKyu766bzGpoPN21q0tjJh6JV1Rp8'
);
 
// get request token and redirect user to twitter authorize page
if (! isset($_SESSION['TWITTER_ACCESS_TOKEN'])) {
	$consumer = new Zend_Oauth_Consumer($config);
	$token = $consumer->getRequestToken();
	$_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token);
	$consumer->redirect();
}
 
// user come back from twitter
if (! empty($_GET) && isset($_SESSION['TWITTER_REQUEST_TOKEN'])) {
	$consumer = new Zend_Oauth_Consumer($config);
	$_SESSION['TWITTER_ACCESS_TOKEN'] = serialize($consumer->getAccessToken($_GET, unserialize($_SESSION['TWITTER_REQUEST_TOKEN'])));
	$_SESSION['TWITTER_REQUEST_TOKEN'] = null;
}
 
// user has granted access ... now we can use the api
if (isset($_SESSION['TWITTER_ACCESS_TOKEN'])) {
 
	$token = unserialize($_SESSION['TWITTER_ACCESS_TOKEN']);
	$userName = $token->screen_name;
 
	$twitter = new Zend_Service_Twitter(array(
		'username' => $userName,
		'accessToken' => $token
	));
 
	$status = $twitter->account->rateLimitStatus();
	// ...
}

Damit man es besser versteht hab ich das in einer Grafik festgehalten …

Keine Hardware Investitionen, nie wieder Server administrieren oder Sicherheitspatches einspielen müssen, das System skaliert automatisch und das Deploy wird einfacher: Das klingt doch alles wunderbar und das alles bietet SaaS!

Platform as a Service (PaaS) gibt es seit einigen Jahren für Java (Google AppEngine) oder für .NET (Microsoft Azure) aber für PHP sieht es derzeit noch etwas mau aus. Diese Lücke möchte jetzt cloudControl aus Potsdam schließen …

Die Features

cloudControl ist in erster Linie eine Webserver-Plattform basierend auf Linux mit Apache und PHP, für eine funktionierende Webapplikation wird allerdings auch eine Datenbank benötigt. Derzeit stehen MongoDb und MySQL in unterschiedlichen Größen zur Auswahl. Maximal kann eine MySQL Datenbank ein Terabyte groß sein. Für MongoDb ist regulär bei 250 GB Schluss, mehr gibt’s aber anscheinend auf Anfrage.

Außerdem stehen noch folgende Add-ons zur Verfügung: Memcached als Caching-Layer, für das Monitoring New Relic RPM und SSL.

Alle Plattform-Funktionen werden über das spezielle Kommandozeilen Werkzeug cctrl gesteuert. Manche Features kann man zusätzlich über die geschützte WebConsole abrufen.

Mit cloudControl lässt sich ein Staging-System mit beliebigen Aufbau realisieren. Jeder Stage (auch Deployment genannt) ist dabei ein eigener Branch und lässt sich mit dem Deploy-Tool separat ansprechen, ein Deploy auf den Test-Stage würde so aussehen:

 
cctrlapp bohuco/test deploy

Die Benutzerverwaltung wird auch über die Kommandozeile gemacht. Der Inhaber einer Applikation kann beliebige Entwickler hinzufügen und entfernen (cctrluser create / activate / delete).

Der Preis

cloudControl rechnet in sogenannten Boxen ab. Eine Box kann 2 PHP Requests pro Sekunde bearbeiten und ist vergleichbar mit einer viertel Amazon EC2 Compute Unit. Die erste Box ist kostenlos, jede weitere kostet 0,05 EUR pro Stunde. Die Boxen werden automatisch auf die aktuellen Anforderungen skaliert bis zu einer Maximalgrenze die der Benutzer festlegen kann.

Alle Features lassen sich kostenlos auf unbegrenzte Zeit testen. Dabei sind die Add-ons auf relativ enge Grenzen gesetzt, wenn man mehr braucht werden dann zusätzliche Kosten fällig die auch stündlich abgerechnet werden. Die kostenlose MySQL-DB darf zum Beispiel nur 5 Mb haben, eine MongoDB 16 Mb.

Handling

Die Kommunikation mit der Plattform wird über ein Kommandozeilen-Tool namens cctrl abgewickelt (in Python geschrieben ???). Das Tool ist für Windows, Mac und Linux verfügbar und die Handhabung wird in verschiedenen Tutorials beschrieben. Für die Source-Code-Versionierung wird standardmäßig Bazar verwendet, man kann aber einfach beim Anlegen eines neuen Projekts Git angeben:

 
cctrlapp APP_NAME create php --repo git

Mein Test-Projekt war innerhalb weniger Minuten angelegt und am Server verfügbar. Folgende Schritte waren notwendig (Mac OSX):

 
mkdir bohuco
cd bohuco
cctrlapp bohuco create php --repo git
vim index.php
git init
git add .
git commit -m "initial commit"
cctrlapp bohuco push
cctrlapp bohuco deploy

Voilà: http://bohuco.cloudcontrolled.com/

Wie man auf dem phpinfo() Screenshot sieht, ist derzeit PHP 5.3.2 installiert, APC ist aktiviert, memory_limit ist auf 128 MB, post_max_size auf 20 MB …

Gehostet wird laut Twitter-Aussage auf Amazon EC2 in Irland: “@brgmn Freut uns, dass es gefällt. Server sind zur Zeit Amazon EC2 EU Region. ^pst”. Einige Details zum technische Setup kann man in den FAQs finden.

Dokumentation und Support

… lassen keine Wünsche offen. Support via Telefon, E-Mail, Twitter und Chat. Die Dokumentation ist umfangreich und gut gegliedert. Tutorials für unterschiedliche Betriebssysteme und sogar einen Cheet Sheet für die wichtigsten Funktionen wurde erstellt.

Performance

Hier die Ausgabe eines ab -n 1000 -c 10 auf meine einfache PHP-Seite. Die Seite macht nur ein echo und die Applikation ist auf eine Box begrenzt.

Server Software:
Server Hostname:        bohuco.cloudcontrolled.com
Server Port:            80

Document Path:          /
Document Length:        28 bytes

Concurrency Level:      10
Time taken for tests:   14.203 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      290000 bytes
HTML transferred:       28000 bytes
Requests per second:    70.41 [#/sec] (mean)
Time per request:       142.027 [ms] (mean)
Time per request:       14.203 [ms] (mean, across all concurrent requests)
Transfer rate:          19.94 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       53   63   5.0     62     105
Processing:    56   79  28.9     69     335
Waiting:       56   78  28.8     69     335
Total:        113  141  29.4    133     400

Percentage of the requests served within a certain time (ms)
  50%    133
  66%    140
  75%    146
  80%    152
  90%    166
  95%    187
  98%    234
  99%    295
 100%    400 (longest request)

Auch Nice …

Das Deployment ist via SFTP zugänglich:
sftp://dep_id@app_name.cloudcontrolled.com/files

Die Log-Files lassen sich abrufen:
cctrlapp bohuco/default log error

Es wird bald ein MySQL Admin Tool geben.

.htaccess ist möglich und mod_rewrite ist aktiv

Fazit

cloudControl sieht auf den ersten Blick wunderbar aus. Wie sich die Plattform im Live-Betrieb bzw. Entwickler-Alltag verhält kann ich nach so kurzer Zeit nicht sagen. Aber das Ding ist auf jeden Fall einen zweiten Blick wert. Fast alles was ich ausprobiert habe hat auf Anhieb funktioniert (nur Apache Access Log konnte ich nicht downloaden).

Usage:

 
$color = new Color();
$color->set('red');
 
echo "red textn";
 
$color->reset(); 
$color->echoString("red text on bluen", 'red_u', 'blue');

The WebSocket class takes a function (or class method) as callback for every socket action, for this example i use the process method of the WebsocketChat Class:

 
$chat = new WebsocketChat();
// new WebSocketServer( socket address, socket port, callback function )
$webSocket = new WebSocketServer("84.38.67.247", 8081, array($chat, 'process'));
$webSocket->run();

The WebsocketChat Class handles user actions and messages. We have two actions: ‘login’ and ‘chat’. ‘login’ happens when a new user sets his username, ‘chat’ is always when a user sends a new message:

 
Class WebsocketChat {
 
	/**
	 * @var array
	 */
	private $messages = array();
 
	public function process($user, $msg, $server){
 
		$msg = json_decode($msg);
 
		if ($msg->action == 'login') {
 
		}
 
		if ($msg->action == 'chat') {
 
		}
	}
}

On the client-side we have to send the right actions if someone clicks ‘login’ or ‘send message’.

 
$('#chat').submit(function(evt){
	evt.preventDefault();
	send({'action':'chat', 'text':$('[name=text]').val()});
});
 
$('#login').submit(function(evt){
	evt.preventDefault();
	send({'action':'login', 'username':$('[name=username]').val()});
	$('#chat').show();
	$('#login').hide();
});

The login action adds a new chat user to the user-array and loads the last five messages for this new user.

 
if ($msg->action == 'login') {
	$user->data['username'] = filter_var($msg->username, FILTER_SANITIZE_STRING);
 
	$max = 5;
	if (count($this->messages)<5)
		$max = count($this->messages);
 
	// on login send last five chat messages
	for($i=count($this->messages)-$max; $i<count($this->messages); $i++) {
		$server->send($user->socket, (string) $this->messages[$i]);
	}
}

If the ‘chat’ action is called then add a new WebsocketChatMessage to the message array and send it to all current chat-users:

 
if ($msg->action == 'chat') {
	$text = filter_var($msg->text, FILTER_SANITIZE_STRING);	
	$lastMessage = new WebsocketChatMessage($user->data['username'], $text, time());
 
	$user->data['message'][] = $this->messages[] = $lastMessage;
 
	foreach($server->getUsers() as $user){
		$server->send($user->socket, (string) $lastMessage);
	}			
}

The WebsocketChatMessage is just a container-class for holding the message data:

 
Class WebsocketChatMessage {
 
	public $text = '';
 
	public $timestamp = 0;
 
	public $username = '';
 
	public function __construct($username, $text, $timestamp) {
		$this->text = $text;
		$this->username = $username;
		$this->timestamp = $timestamp;
	}
 
	public function __toString() {
		return sprintf('%s %s: %s', strftime('%H:%M', $this->timestamp), $this->username, $this->text);
	}
}

View Chat Example on BOHUCO Labs

View server.php Code

Der Erklärbär erklärt’s! (er versucht es zumindest)

AOP … was?! Noch nie gehört, oder doch?! … Ja auch die AOP gibst schon einige Jahre aber es dauert hald immer ein wenig bis die Sachen bei den Webentwicklern ankommen. Grundsätzlich geht es beim Aspect Orientierten Design darum die Schwächen der Objektorientierten Entwicklung auszubessern …

“Wie, was Schwächen der OOP?” … Ja klar, man kann zwar alle Klassen überschreiben oder erweitern aber was ist wenn man nur einen kleinen Teil einer Methode ändern will, dann muß man immer gleich die ganze Methode duplizieren und den kleinen Teil umschreiben. Aber das erzeugt viel unnötigen zusätzlichen Quelltext. Ausserdem kann es sein das diese Form der Erweiterung nicht Möglich ist und man an diversen Stellen dann die Methoden-Aufrufe umschreiben muß …. das will doch wirklich Keiner!

“Und AOP machts besser?” Ja, machts viel besser! Im Wikipedia wirds a bissl kompliziert erklärt: Verschiedene Aspekte (Concerns) die die ganze Applikation betreffen Bla Bla … … Konkret und einfach gesagt: Man kann hald net immer alles in ein Klassensystem pressen, gerade applikationsübergreifende Elemente wie Logging, Caching oder Parameter-Behandlung passen da überhaupt nicht rein und da springt dann die AOP ein.

Beispiel Logging:

In eine Methode ein Logging einzubauen ist ja relativ einfach:

public function doSomething() {
    $this->logger->log('start doSomething');
    // do something
    $this->logger->log('end doSomething'); 
}

Wunderbar! Jetzt hat man da den Logger drin und nach einer Woche will man aber auch an den selben Stellen etwas zusätzliches oder anderes machen lassen, Caching zum Beispiel, also bastelt mans dazu:

public function doSomething() {
    $this->logger->log('start doSomething');
    if ($this->inCache()) {
        // return from cache
    }
    // do something
    $this->logger->log('end doSomething'); 
}

Das wär ja auch noch ganz OK wenn man den Cache überall verwenden will, aber er soll hald nur unter gewissen Voraussetzungen verwendet werden, dann kann mans jetzt entweder der Methode als Parameter übergeben, oder als Klassenvariable dem Konstruktor, beides will man nicht weil man dann alle Aufrufe anpassen müsste (im schlimmsten Fall).

Rettung: Signals and Slots

Darum baut man sich einen “Signal Slot” hinein, früher hätte ich gesagt einen “Callback-Hook” oder im WordPress nennen sie es “Action”. Ein Signal markiert eine bestimmte Stelle im Quelltext aber ohne eine konkrete Aufgabe zu haben, in diesem Fall hätten wir ein Start-Signal und einen End-Signal, via Slots kann man den Signals eine Aufgabe zuordnen die aber nur in dem einen bestimmten Fall gilt und alle anderen Aufrufe nicht betrifft:

public function doSomething() {
    $this->signals()->emit('start');
    // do something
    $this->signals()->emit('end');
}
 
// attach slots somewhere else in the application
$class->signals()->connect('start', $log, 'info');
$class->signals()->connect('log', $log, 'info');

Nachteile der ganzen Sache: Wenn man die Signal-Slots ausgiebig verwendet, hat man hald viele “leere” emit-Calls im Quelltext die natürlich auch etwas Zeit für die Ausführung beanspruchen, also bissi schlechtere Performance. Nächster Nachteil, wenn man die Signals nicht vernünftig benennt oder dokumentiert kennt sich kein Schwein mehr aus, siehe WordPress! Die Verständlichkeit des Quelltexts leidet auch darunter weil man nicht mehr genau weiß was eine Methode macht ohne sich auch die Slots anzusehen.

… Licht und Schatten, aber bei WordPress funktioniert’s trotz der angesprochenen Probleme wunderbar. Jeder Entwickler kann aufgrund der vielen Signals (Actions) die eigene Logik in das Grundsystem integrieren ohne es anzugreifen. Und das Grundsystem bleibt damit weiterhin updatebar – voi cool gell!

Wikipedia: Signals and Slots
Wikipedia: AOP
Phly, boy, phly – Aspects, Signals, Filters
PHP Advent 2010 – AOD

Im Teil 2 wird der Erklärbär dann Aspect-Oriented Filters erklären … das wird wieder ein Spaß (oder?).

You can test the Google Ranking Checker Class on BOHUCO Labs:

http://bohuco.net/labs/google-ranking-check

… or Download the Source-Code:

http://bohuco.net/labs/google-ranking-check/RankingChecker120.php.gz

Usage Example:

 
require_once 'RankingChecker.php';
$rankingChecker = new RankingChecker($apiKey);
$rankingChecker->setLocale('de', 'at');
$rankings = $rankingChecker->check(array('bohuco'), array('bohuco.net'));
 
var_dump($rankings);

Thanks for all the comments and suggestions.

First copy the pem file to the hidden .ssh folder and add the content of the pem-file to your keychain:

cp mypemfile.pem ~/.ssh
ssh-add -K ~/.ssh/mypemfile.pem

Next open the ssh-config file (usually its empty) …

vim ~/.ssh/config

… and add the config for you instance:

Host public-ec2-dns.compute.amazonaws.com
HostName public-ec2-dns.compute.amazonaws.com
User root
IdentityFile ~/.ssh/mypemfile.pem

Download MacFusion
Amazon EC2
see superuser.com