Android App URL Schemes

This is a functioning AndroidManifest.xml for linking via a local url scheme. In this case appname:// with any (*) following path

To test this you have to redirect to it. Chromium at this time does not understand or process app url schemes. So a 302 redirect from a trusted publicly available url is the best method for testing.

Note how the second intent-filter here is still inside the .MainActivity <activity>

Different categories and an additional <data> tag are used.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.appname">

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> 
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>

    <application
      android:name=".MainApplication"
      android:label="@string/app_name"
      android:icon="@mipmap/ic_launcher"
      android:allowBackup="false"
      android:theme="@style/AppTheme">
      <activity
        android:name=".MainActivity"
        android:label="@string/app_name"
        android:configChanges="keyboard|keyboardHidden|orientation|screenSize"
        android:windowSoftInputMode="adjustResize">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <action android:name="android.intent.action.DOWNLOAD_COMPLETE"/>
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
          <intent-filter android:label="@string/app_name">
              <action android:name="android.intent.action.VIEW" />
              <category android:name="android.intent.category.DEFAULT" />
              <category android:name="android.intent.category.BROWSABLE" />
              <data android:scheme="appname" android:host="*" />
          </intent-filter>
      </activity>
      <activity android:name="com.facebook.react.devsupport.DevSettingsActivity" />
    </application>

</manifest>

Two Factor Authentication on Twitter is Broken

The online security of you and your friends and family is more at risk now than it’s ever been. People are still regularly using the same username and password across most, if not all their online accounts. Any leak of one set of access details is a leak of all their access details.

When two factor authentication was launched it became a saviour for these people. You would need physical hardware to generate or receive a one time code, as well as your username and password.

Twitter implemented this initially as SMS only one time code sending. You added your mobile number to your Twitter account and it would start sending codes at the point of login and requiring the code to login successfully.

The first version would only allow your mobile number to be connected to a single account, so if you wanted to secure multiple accounts you were out of luck.

There is also a flaw in the SMS system though which can allow hackers to redirect the security code to any number they choose. It’s not widely used, but still exists.

More recently Twitter added the ability to use other methods of two factor authentication. Apps like Last Pass, 1Password and Authy allow you to store all your access details behind a single master password.

Sounds great right? No more relying on mobile phones. Well, no. The trouble is, that to use a password manager with Twitter, you first have to add your mobile number to your Twitter account. You then have to manually disable the SMS option to stop Twitter always sending the SMS codes.

The kicker here is that if you remove your mobile phone number from your Twitter account, it also removes any other two factor authentication you’ve set up.

You cannot have two factor authentication on your Twitter account if you don’t have a mobile phone linked to the account.

This is an astonishing requirement, and one many security experts are calling short-sighted and even a dark pattern.

You would hope that Twitter would put security before all else, but in this case that doesn’t seem to be so.


You can find me on twitter via @HarryBailey

Yii upgrade service

Yii 1.1 is currently in maintenance mode following Yii 2 being released way back in May 2013.

Support and bug fixes for Yii 1 were only provided until December 31, 2016 and security fixes and PHP 7 compatibility ends December 31, 2020.

That means that right now the only reason updates to Yii 1 are being created and made available are for security issues found in the existing codebase, and from 2021 it’s mothballed completely.

If you’re maintaining a Yii 1 codebase it’s time to start thinking about how to migrate away from Yii completely, or upgrade your codebase to Yii 2.

There is an official guide aimed at supporting the upgrade process, but it is unlikely to get you from Yii 1 to Yii 2 without significant pain and head scratching.

Converting from Yii 1 to Yii 2 is completely unlike developing code for either framework, and you’d want to source a Yii upgrade professional rather than getting an inexperienced developer or team involved with a large or mission critical codebase.

Personally I’ve now upgraded four codebases from Yii 1 to Yii 2. All the upgrades have been different. All follow a similar path, and the repeatable process I’ve created, but each has its own edge cases, bespoke widgets and complexities.

The work takes many days per codebase before testing and perfection can happen, and where an existing development team are involved with ongoing development or support of the Yii 1 system, it’s best handled as a team effort. Acceptance that the process isn’t anywhere close to just flicking a switch or downloading a patch is required from day one.

At this point I’m considering two next steps.

Firstly, if your company has significant budget and is in need of support moving from Yii 1 to Yii 2, I’d be interested in hearing from you. You may want a supportive voice helping your existing developers to make the move. You may also be looking to hand over a Yii 1 codebase and get it back ready for some testing and iteration.

Secondly, I’m considering sharing some or all of the process I’ve created for manually moving a codebase over from Yii 1 to Yii 2, the gotchas, the process and how to update specific things within Yii 1, where it isn’t as simple as a like

Feel free to send me a direct message on Twitter @harrybailey or leave a comment below if you’d like to contact me.

Yii 1, PHP 7.1, yii-pdf and Mpdf

Mpdf 6.x only supports PHP versions up to 7.0. If you’re upgrading your local machine, or hosting environment to PHP 7.1 or beyond (you should be) then you’ll need to upgrade your Mpdf install to something more recent than 6. That requires a few changes.

Now just to make things complex here, the latest version of Mpdf happens to be version 7.1. From here on I’ll try and prefix any version numbers with either PHP or Mpdf.

Mpdf 7 and greater is composer install only. You could still download and copy the files into place, but I highly recommend using composer to manage your vendor packages in Yii (and Yii 2). It will save you hours and hours over time.

Mpdf 7 has updated it’s class name to be Mpdf with a capital M, and changed it’s construct method to accept a config array instead of separate parameters. Small but significant updates we’ll have to deal with.

If you’re already using composer, then you’ll have a composer.json file in the root of your codebase, and in there you should have a line which starts “mpdf/mpdf”.

That line will probably end something like “^6.0” or “^6.4”

Assuming it’s less than “7.x.x” we’re going to update with composer.

Back up your codebase. I shouldn’t have to mention it, but do it, honest.

Run composer require mpdf/mpdf “^7.0”

That line will install the latest version, Mpdf 7.1, allow anything newer to be installed if you update in the future, and change your composer.json file (and likely your composer.lock file too) to include the newer information.

So we have the latest code, but we need to update Yii to use it.

yii-pdf wraps mpdf and makes it available via Yii->app()->ePdf->mpdf()

The yii-pdf config to get it functioning with Mpdf 7+ will look something like this:

'ePdf' => [
	'class' => 'application.extensions.yii-pdf.EYiiPdf',
	'params' => [
		'mpdf' => [
			'librarySourcePath' => 'vendor.mpdf.mpdf.src.*',
			'constants' => [
				'_MPDF_TEMP_PATH' => Yii::getPathOfAlias('application.runtime'),
			],
			'class'=>'\Mpdf\Mpdf',
			'defaultParams' => [
				'mode' => '',		//  This parameter specifies the mode of the new document.
				'format' => 'A4',	// format A4, A5, ...
			],
		],
	],
],

Note the librarySourcePath and class values. You can add your existing defaultParams and anything else which was in your preferences previously.

The last part is to update all places where you call the mpdf library. Previously it would have looks something like:

$mpdf = Yii::app()->ePdf->mpdf('UTF-8', '', 0, '', 15, 15, 15, 15, 8, 8);

We now convert the config to be an array of values:

$mpdf = Yii::app()->ePdf->mpdf(['UTF-8', '', 0, '', 15, 15, 15, 15, 8, 8]);

And that should be it. Update using composer, update your config, update all locations you instantiate mpdf. Then check your pdf generating code is still functioning.

Security of WHM backups to an AWS S3 bucket

When you give your Web Hosting Manager (WHM) the ability to send a copy of your backup to Amazon’s AWS S3 service, you have to hand it a Key and Secret that give it that permission.

The worst option is to hand over a Secret and Key related to your own log in.

The best is to:

  1. Create a policy which
    • Only gives access to a single bucket
    • Only allows the least access required for the task
    • Only allows connections from trusted IP addresses
  2. Create a Group to connect the policy to
  3. Create a user (for the WHM) to connect to the group

For validation of connection to S3 WHM currently requires the ability to write objects, list all objects in a bucket, delete objects. Now for some this is frustratingly more than you want to hand over. In theory WHM could make do with just the ability to write to the bucket, but at the moment we have to make all those abilities available.

Luckily, the fact we’re also limiting by IP and then Secret and Key—which WHM encrypts when you submit them—should make it highly unlikely anybody else will be able to abuse the ability to delete objects.

Here is the example policy that I have in place. Feel free to copy, personalise and use:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "WHMBackupAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "YOUR_SERVER_IP/32"
                }
            }
        }    
    ]
}

If you’re in need of help putting this all together, let me know and I might expand this post to include how to do the setup inside WHM and the AWS console.