apt get life

Life around technology

You are here: Home / Archives for php

Optimising Nginx for PHP & WordPress (Time To First Byte)

by

When running page speed insights, it seems that TTFB (Time To First Byte) is something that it really doesn’t like when checking performance.

To solve this, we can use nginx’s caching of compiled PHP pages. Even better, the cache can be a RAM disk, making it very responsive.

First, create a directory for the RAM disk:

sudo mkdir -p /mnt/nginx-cache

Now create an entry in the fstab file so it’s mounted to the RAM disk on boot:

sudo nano /etc/fstab

tmpfs /mnt/nginx-cache tmpfs rw,size=2048M 0 0

This creates a 2GB RAM disk. Edit the size as appropriate for your server. Then mount it:

sudo mount /mnt/nginx-cache

Now, create a cache configuration file for Nginx:

sudo nano /etc/nginx/conf.d/cache.conf

fastcgi_cache_path /etc/nginx-cache levels=1:2 keys_zone=phpcache:512m inactive=2h max_size=1024m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

This creates a cache of 1GB with a default time of 2 hours. Next update the config files for your website – change your config file name where appropriate.

/etc/nginx/sites-enabled/mysite.conf

Inside of the location ~ "^(.+\.php)($|/)" { section, add:

# ----------------------------------------------
# Caching
# ----------------------------------------------
# This defines which cache to use (defined in /etc/nginx/cache.conf)
fastcgi_cache phpcache;
# Cache only 200 Okay responses for 2 hours
fastcgi_cache_valid 200 2h;
# Don't cache POST requests, only GET
fastcgi_cache_methods GET HEAD;
# Optional. Add a header to prove it works
add_header X-Fastcgi-Cache $upstream_cache_status;

now you should be able to restart nginx sudo service nginx restart and access the site via a web browser. Then you can use something like developer tools access the headers of the web requests. You should find a header:

X-Fastcgi-Cache: HIT

 

Laravel 5.2 API Token Authentication

by

At work I’ve been tasked with improving an API recently, and I decided it would be a good opportunity to take Laravel out for a spin. I’ve been keen on learning more about laravel and it’s API capabilities which are supposedly very strong, although I have noted that there’s not much documentation around them. The existing API is flat PHP and uses token based authentication. This allows users to authenticate with a string “api_key” in the request URL, in the header or in the body of the JSON request. I decided that instead of trying to get existing users to upgrade to something like oAuth (for which there are some interesting plugins https://packagist.org/packages/lucadegasperi/oauth2-server-laravel), I’d just implement the same token based authentication model for the revised API in Laravel. There are already advantages to using Laravel for APIs – it highly encourages a restful approach, as for Laravel 5.2 it includes rate limiting out of the box and allows for route prefixing, so it is possible to have multiple endpoints in one Laravel application.

Setting up token based authenticaton in Laravel is so poorly documented that it took me a while to work out how it is achieved.

1. User API Tokens

Users need to have an API token to be associated with them in order to allow the authentication model to work. This is easy enough to add by editing the user migration in your laravel installation.

// Store an API key for this user.
$table->string('api_token', 60)->unique();

This allows you to store a 60 character unique API Token for each user.

2. Setting up API Authentication

There are several ways you can now call API Token authentication for your application. Probably the best is to use middleware in your routes file:

Route::group([
    'prefix' => 'api',
    'middleware' => 'auth::api'
    ], function() {
    Route::resource('fruit', FruitController);
});

Now any time requests are made to the route group, the API authentication method will be called. This includes token based authentication (now defined in the users table) as well as the API rate limiting.

3. Making API Requests

You can now submit your API requests to see if the Laravel token authentication is working. To do this you can submit “api_token” as either a GET or POST paramiter. There’s also hidden away the option to have it set as a header, however this requires you to use an Authorization header:

Key: ‘Authorization’

Value: ‘Bearer [token]’

Check out the code here:

https://github.com/laravel/framework/blob/c04159dee4a47b0d7cd508ab720932121927b1b3/src/Illuminate/Http/Request.php#L815-L822

and here:

https://github.com/laravel/framework/blob/master/src/Illuminate/Auth/TokenGuard.php#L81-L94

 

Linux servers – using ClamAV to find malware

by

ClamAV is an open source anti-virus program that can be run from the command line, making it incredibly useful for locating any viruses and malware on Linux based servers. Recently someone I’ve previously worked with reported that they’d had reports of abuse originating form one of their servers. Given the quantity of sites, it was difficult to locate any potential vulnerabilities.

grep -RPl --include=*.{php,txt} "(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(" /var/www/

 

Blindly grepping for potentially malicious strings such as “base64_decode” and “exec” was getting tired fast, as these can be legitimately used for some applications. I stumbled across reports that ClamAV works well for locating potential threats

nice -n 19 clamscan ./ -r -i | grep " FOUND" >> possible_exploits.txt

You can then review these files as you see fit, editing the file to remove ones that are false positives. I then run a command to delete the infected files:

while read f; do rm $f ; done<$possible_exploits.txt

 

Setting up PHP XDebug in PHPStorm

by

Setting up XDebug in Apache

First off, ensure that the modules have been installed for php and xdebug:
sudo apt-get install php5-dev php5-cli php-pear
sudo pecl install xdebug

Now the packages should be installed, we need to find the default location for PHP and xdebug. Take note of both resulting directories:
which php5
sudo find / -name 'xdebug.so'

Horrah, we have our paths for the xdebug plugin so we can edit the approrpaite PHP files. There are two exciting options here:

Number 1 – you can edit PHP ini directly and add the code (later)

sudo nano /etc/php5/apache2/php.ini

Number 2 – you can edit the conf.d/20-xdebug.so file and edd the code (later)

nano /etc/php5/apache2/conf.d/20-xdebug.ini

Code for PHP.ini or 20-xdebug.so:

# This should be the directory you received from the find command you used earlier
zend_extension = /usr/lib/php5/20121212/xdebug.so
# These settings enable a connection to sublime text.
# If you're using PHP storm you can use the same settings,
# with other programs mileage may vary
zend_extension=xdebug.so
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_autostart=1

Now it’s a good idea to restart apache so xdebug is loaded:

sudo /etc/init.d/apache2 restart

 

Setting up XDebug in PHPStorm

At this point you will need to open PHP Storm to configure it with Xdebug. Once it’s open go to:

File -> Settings

Select PHP from the left hand menu

click … on interpreter

hit the “reload” button and xdebug should appear.

Click ok.

click debug on left hand column

make sure xdebug options are enabled.

Bookmarks

You need to create new book marks in your web browser. You can either follow the guide at it’s source, or keep following what’s in the article:
http://www.jetbrains.com/phpstorm/marklets/

Start xDebug


javascript:(/** @version 0.5.2 */function() {document.cookie='XDEBUG_SESSION='+'PHPSTORM'+';path=/;';})()

Stop xDebug


javascript:(/** @version 0.5.2 */function() {document.cookie='XDEBUG_SESSION='+''+';expires=Mon, 05 Jul 2000 00:00:00 GMT;path=/;';})()

Debug this page


javascript:(/** @version 0.5.2 */function() {document.cookie='XDEBUG_SESSION='+'PHPSTORM'+';path=/;';document.location.reload();document.cookie='XDEBUG_SESSION='+''+';expires=Mon, 05 Jul 2000 00:00:00 GMT;path=/;';})()

Run a Remote PHP Web Script from the Command Line with WGET

by

So, you have a webpage that runs a script which you need to automate? Command line and contab to the rescue!

 

Wget, the linux command line tool can “get” PHP pages and execute them, displaying the contents in an output file. This makes it incredibly useful for managing automated jobs inside content management systems. It’s really simple to use:

wget -q -O output.log "http://example.com/example_script.php"

wget simply runs setting the output to a logfile with the request at your webpage’s script as a full URL. Quotes around the URL are highly recommended. You can tell if the script has finished by looking at output.log and making sure the closing HTML tag is there.

It’s really easy to add this to a crontab for automation. Simply edit your crontab from the terminal interface (crontab -e) and add the line as you require:

0 6 * * * wget -q -O output.log "http://example.com/example_script.php"

This runs the wget command at 6am every day.