My own WP site here is protected with Google Authenticator, and there is no excuse for not doing the same on yours. Just grab the awesome WP Google Authenticator plugin and you will be good to go.
My favourite iOS App for this is the awesome Authy but there are plenty out there.
But the world doesn’t run on WordPress, suppose you want to do it yourself in a LAMP site…
Grab a copy of the PHPGangsta class
$ga = new PHPGangsta_GoogleAuthenticator();
$secret = $ga->createSecret();
echo "Your OTP Secret is: ".$secret."\n\nIt is probably a good idea to take a note of this";
echo "\nPlease scan in the QR code to setup your OTP ";
$qrCodeUrl = $ga->getQRCodeGoogleUrl('MyApp', $secret);
<IMG SRC='<?php echo $qrCodeUrl?>'>
<BR>
<?php
$oneCode = $ga->getCode($secret);
$checkResult = $ga->verifyCode($secret, $oneCode, 2); // 2 = 2*30sec clock tolerance
if ($checkResult) {
echo 'OK';
$sql="UPDATE localusers set GASecret='" . $secret . "' WHERE id=" . $userRow['id'];
mysqli_query($link,$sql);
} else {
echo 'FAILED';
}
if(!isset($userRow['GASecret']) || !isset($_REQUEST['e'])) { // Impossible to Authenticate
header('HTTP/1.1 401 Authentcation Impossible');
header('Content-Type: application/json; charset=UTF-8');
die(json_encode(array('message' => 'ERROR', 'code' => 1337)));
} else { // Try to authenticate
$ga = new PHPGangsta_GoogleAuthenticator();
$checkResult = $ga->verifyCode($userRow['GASecret'], $_REQUEST['e'], 2); // 2 = 2*30sec clock tolerance
if($checkResult) {
session_write_close();
session_start();
$_SESSION['OTP'] = 1;
session_write_close();
$result="Authenticated";
header('Content-Type: application/json');
die(json_encode($result));
} else {
header('HTTP/1.1 401 Authentcation Failed');
header('Content-Type: application/json; charset=UTF-8');
die(json_encode(array('message' => 'ERROR', 'code' => 1337)));
}
Obviously these are just snippets, which will never actually run for you, but you get the general idea.
It is so easy, it is just rude not to.
]]>This means that the input get’s passed around through JS, AJAX, PHP and goodness only knows what before it turns up in the right place.
How do we make sure it’s safe to add to a SQL query?
Of course we can use PDO, but how about the general case?
$Words=str_replace(“\xA0″,” “, mysqli_real_escape_string($link,html_entity_decode(strip_tags(preg_replace(‘!\s+!’, ‘ ‘,trim($Words))))); $pieces=explode(” “, strip_tags($Words)));
Something just says this is plain wrong, but it’s working for me.
In this particular use case I’m trying to break up a user provided “sentence” into a set of words, which I then do stuff with.
So is particularly difficult to parse here when things get pasted.
I’m sure the above approach is wrong, would anyone like to tell me how to do it better?
]]>Still it does have a very useful role to play, even if some of the things it does just seem plain strange. Yes, EasyApache does give enormous flexibility, but so do the vendor provided packages.
Some days the only way to fix things is through SSH’ing into the server, and you have to be really careful to make sure that you don’t change something at the command line that WHM has it’s claws into.
suPHP seems to be the default handler (I can kind of understand why for multi-tenant hosting setups, but perhaps you should have a real sys-admin hired in that scenario?). It has a charming habit of doing the unexpected; todays head banging surprise came from wondering why php.ini settings were not getting applied.
After lots of grepping for ini-set statements, we eventually find an suPHP_config directive in .htaccess.
*sigh*
.htaccess has a lot to answer for, and if you are looking for real web performance you should _NEVER_ use .htaccess – put the configuration in the Apache configuration file where it belongs. The additional cycles Apache has to spend checking for the presence of .htaccess and parsing it if it is there will hurt you in the long run.
Allowing your “webmasters” to specify their own php.ini through .htaccess is just plain wrong.
Rant ends.
]]>