Apigility Oauth2 Clients

This is mainly for my own notes (I’ll update), but I’m going to use OAuth2 for an API I’ll be building using Apigility. First thing I did was add a client into the oauth_clients table. the password should be bcrypted, and as I’m doing a server to server situation (my web site (the client) to the api) i type authorization_code into the grant_type. In the redirect_url put /oauth/receivecode

Next up I had issues getting the Postman client OAuth setup to work correctly, so I decided to use an awesome cli alternative, HTTPie, which can be installed by sudo apt-get install httpie.Run the following command to request an authorization code:

http --verify no -f POST https://api.awesome.del/oauth/authorize client_id=testclient response_type=code  redirect_uri=/oauth/receivecode state=xyz authorized=yes

The –verify no option stops it freaking out if the SSL certificate (OAuth2 MUST be used on port 443!) is a self signed one. We pass in the client_id, response_type, a redirect_uri, state can be anything (available to use for csrf?), and authorized=yes is the form variable on apigilities authorization page. You should get something like this:

HTTP/1.1 302 Found
Connection: close
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Tue, 28 Jul 2015 05:36:56 GMT
Location: /oauth/receivecode?code=668d8b8d8ac4442fdf51419bf89c33f8b49f9971&state=xyz
Server: Apache/2.4.12 (Ubuntu)

As you can see, $_GET[‘code’] is there. Once we have authorised a client to the api, it adds a row to oauth_authorization_codes, with the client, callback, and an expiry date not long at all after being generated. Using the code variable, you run the following command:

http --verify no -f POST https://api.awesome.del/oauth client_id=testclient client_secret=testpass grant_type=authorization_code  redirect_uri=/oauth/receivecode code=668d8b8d8ac4442fdf51419bf89c33f8b49f9971

If all is going well you should see this:

HTTP/1.1 200 OK
Cache-Control: no-store
Connection: close
Content-Type: application/json
Date: Tue, 28 Jul 2015 05:43:02 GMT
Pragma: no-cache
Server: Apache/2.4.12 (Ubuntu)
Transfer-Encoding: chunked

{
    "access_token": "a920d6e7d85a2eb6225c07efb17c0f1fb7b5e9e6", 
    "expires_in": 3600, 
    "refresh_token": "fea627801b8d1d4fce095c7cef6dde7c0d3b5850", 
    "scope": null, 
    "token_type": "Bearer"
}

Now that you have the access_token and refresh_token, we can start calling the sections of our api that we secure up! Currently I have a /ping endpoint that returns the server time, just for testing connectivity. In the Apigility Panel, click on the name of the API, and set the authentication type to your OAuth2 one. Then in your api service (ping in my example), in the authorization tab, click GET checkbox to run authorization on GET /ping. Now if you access /ping without authorisation, you should see the following:

{
  "type": "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html",
  "title": "Forbidden",
  "status": 403,
  "detail": "Forbidden"
}

So we need to access with our access_token. At this point I ran into an annoying problem, which to save you a lot of hassle, was this; that Apache 2.4 is set by default to strip out the Authorization Header! Amazingly, my answer was in my own post about getting Basic HTTP Authentication working in puPHPet! You need to set in your vhosts (or in my below example, the puphpet config.yaml) a setenvif:

setenvif:           
     - 'Authorization "(.*)" HTTP_AUTHORIZATION=$1'

Reprovision your puppet box or restart apache if you edited your vhosts file. No we should be able to accept requests with an access_token:

http --verify no GET https://api.awesome.del/ping "Authorization:Bearera920d6e7d85a2eb6225c07efb17c0f1fb7b5e9e6"

And you should see:

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json; charset=utf-8
Date: Tue, 28 Jul 2015 21:06:10 GMT
Server: Apache/2.4.12 (Ubuntu)
Transfer-Encoding: chunked

{
    "ack": "2015-07-28 21:06:12"
}

So now we have resources which can be set public, and which can require authorisation. I’ll update this once I learn some more about the oauth_scopes. Have fun 🙂

Disable default Inspect Element in Firefox (we use Firebug!)

If you use and love Firebug like me, you may also have been driven mad accidentally clicking the wrong Inspect Element!

Thankfully, it’s real easy to sort. Browse to about:config, search for the setting extensions.firebug.hideDefaultInspector, and change it to true!

No more irritating wasted seconds!

puPHPet Box MySQL backup

As you all know by now, I love puPHPet. And I like tinkering with things. Which of course leads to the occasional breaking of things. And then I realised, okay, your sites files are being mounted into this virtual machine, what about the databases though?

The great thing about puPHPet and Vagrant is you can build a full server up from scratch in minutes. The one downside is that it cant be smart enough to uninstall things. If you add lines to your config.yaml it will install something, but removing those lines means puPHPet won’t even know it was there, so how would it know to uninstall it? The exceptions of course being the ones which have their own config.yaml entry, with an install: ‘1’ or install: ‘0’

Anyway, I generated me a new config and was about to blitz my old VM when the usual gut instinct checks kicked in, and the DB sprung to mind immediately. So I made a quick backupdbs.sh shell script (courtesy of a StackOverflow post) which makes individual sql files for each of your DB’s. I decided I would keep the script in my mounted sites folder in a bin directory. So hence it lives in /var/www/bin/backupdbs.sh

#!/bin/bash

USER="root"
PASSWORD="YOURPASSWORDHERE"

databases=`mysql -u $USER -p$PASSWORD -e "SHOW DATABASES;" | tr -d "| " | grep -v Database`

for db in $databases; do
    if [[ "$db" != "information_schema" ]] && [[ "$db" != "performance_schema" ]] && [[ "$db" != "mysql" ]] && [[ "$db" != _* ]] ; then
        echo "Dumping database: $db"
        mysqldump -u $USER -p$PASSWORD --databases $db > `date +%Y%m%d`.$db.sql
    fi
done

To back everything up, vagrant ssh into the machine, then (you’ll probably need to switch user to www-data) do the following:

sudo su www-data
cd /var/www/bin
./backupdbs.sh

Now you’ll find all your DB’s SQL files date stamped in the folder! You can continue to break, tweak, fix, and run your VM to your hearts content 😀