Academe Computinghttps://academe.co.uk
Web, tech, open sourceMon, 05 Mar 2018 13:00:24 +0000en-UShourly1https://wordpress.org/?v=4.9.8bash script to switch PHP versions in Plesk command linehttps://academe.co.uk/2017/08/bash-script-switch-php-versions-plesk-command-line/
https://academe.co.uk/2017/08/bash-script-switch-php-versions-plesk-command-line/#commentsThu, 31 Aug 2017 12:12:28 +0000https://academe.co.uk/?p=1552I found myself needing to switch between PHP versions on the command line running under the Plesk environment on a CentOS server. Some apps ran under PHP 5.6, some under 7.0 and others being pushed towards 7.1. This script allows me to be quickly switch between them. It looks for the current PHP version in […]

]]>I found myself needing to switch between PHP versions on the command line running under the Plesk environment on a CentOS server. Some apps ran under PHP 5.6, some under 7.0 and others being pushed towards 7.1. This script allows me to be quickly switch between them. It looks for the current PHP version in the PATH and changes just that.

My shell scripting is a little rusty, so you may have some improvements. It shows the PATH before and after, so you should be able to spot if it breaks things, and quickly fix it.

]]>https://academe.co.uk/2017/08/bash-script-switch-php-versions-plesk-command-line/feed/4OmniPay/Authorize.Net DPM Sequence Charthttps://academe.co.uk/2015/06/omnipayauthorize-net-dpm-sequence-chart/
https://academe.co.uk/2015/06/omnipayauthorize-net-dpm-sequence-chart/#commentsSun, 28 Jun 2015 17:29:21 +0000http://academe.co.uk/?p=1425In part 1 I introduced some of the Authorize.Net gateways, in particular the Direct Post Method (DPM) gateway. I also introduced the OmniPay package that handles the DPM gateway. The code samples that follow will focus on DPM. To provide some context, I’ll bring in a sequence chart for this gateway used through OmniPay. What […]

]]>In part 1 I introduced some of the Authorize.Net gateways, in particular the Direct Post Method (DPM) gateway. I also introduced the OmniPay package that handles the DPM gateway. The code samples that follow will focus on DPM.

To provide some context, I’ll bring in a sequence chart for this gateway used through OmniPay.

What is a Sequence Chart?

When payments are authorised through payment gateways, there is a complicated flow of data between the user, the merchant application (e.g. the shop) and the payment gateway. This is mediated by OmniPay, which handles the messaging between all these systems. Understanding what those flows are, helps in putting the application together.

A sequence chart shows the flow of data between the disparate systems. In the sequence diagram below, the systems are the Authorize.Net gateway, the merchant application front end (what the user interacts with), the merchant application back-end storage, and the merchant application back-channel handler (where Authorize.Net contacts the application directly). I have tried to show where that data flows through the OmniPay gateway driver.

So starting from the top, we first collect what information we have about the user, in the “glue”. The glue code is what we create to join the merchant application to OmniPay. The information we may have about the user could include their shipping and billing address, name, email address, or we may know nothing about them at all. If the user is logged in, then it makes sense to pre-fill any payment forms with details that we do know, to save them typing out those details again.

In addition we need to collect the details of what the user is authorising payment for – the total cost of their shop basket or cart, or the due amount on the invoice they are paying.

Then we go through a few steps to generate the POST form the user will see. Start by creating the gateway object:

Next we create a transaction ID. The transaction ID in OmniPay is the unique ID that a merchant application will give to the transaction being authorised. The function generateTransactionId() here will generate a new unique ID for the merchant site.

$transactionId = generateTransactionId();

Next we need to create a CreditCard object. This object is a bit of a misnomer in OmniPay version 2. It is used to log all details we have about the customer – name, addresses, emails, and of course, the credit card details. In this case, using DPM, we leave the credit card details empty, since we are not (and have not) captured them.

There are other details that can be supplied, but these make up a sensible minimum.

Two important fields are the returnUrl and the cancelUrl. The cancelUrl is where the user is sent if they hit any of the cancel links when making or authorising a payment.

The returnUrl, for this gateway driver, is the URL in the merchant application that Authorize.Net will use to notify the application of the result – commonly called the notification URL where the notification handler will be found. Note that there is no “completion URL” in this data. That destination is supplied by the notification handler.

Different gateways that use a notification handler work in different ways. Some require the final completion URL to be set right at the start, some expect it to be supplied by the notification handler, and some may have it defined the gateway account rather then anywhere in the code.

So this gives as a request object, containing all the data needed to make a request. This is “sent” to get the result like this:

$response = $request-&gt;send();

Now, this can be a little unintuitive. We are asking OmniPay to “send” this request in order to get a response. However, we are not sending anything to the remote gateway at this stage. Some gateway drivers will send send a message to the remote gateway at this point, and that is where the language comes from, and the idea is to keep it the use of different gateway drivers as consistent as possible but it can result in some steps feeling a little strange.

So we “send” the authorize message and get a response in return. That response is there to tell us what to do next. With some gateways there may not be a following action – the transaction may be complete right here. Some gateways may require the user to be redirected to the remote gateway site to supply their credit card details. This gateway driver is different – it expects the user to present a payment form to the user, and the response object provides some tools to help this process.

Before we present the payment form to the user, there are two things to save. First the transactionId needs to be saved in the session. We will need that when we return from Authorisze.Net. Here we save it using the Laravel Session façade, but you use whatever your framework provides:

Session::put('transactionId', $transactionId)

Secondly we need to save the details of the transaction authorisation response. The transaction will be indexed by the transactionId, so we can fetch it again later. Its initial purpose is to provide details for the notification handler to check up against, so it needs to have a status indicating that it is waiting for the notification, and the amount needs to be stored for a further check in the notification handler.

]]>https://academe.co.uk/2015/06/omnipayauthorize-net-dpm-sequence-chart/feed/7Laravel 5 – Naming Logfiles According to OS Userhttps://academe.co.uk/2015/06/laravel-5-naming-logfiles-according-to-os-user/
https://academe.co.uk/2015/06/laravel-5-naming-logfiles-according-to-os-user/#respondWed, 03 Jun 2015 21:59:10 +0000http://academe.co.uk/?p=1408Apologies in advance for the formatting of the code. WordPress is, basically, shit at handling any kind of formatting that is not its own flavour of HTML, so it plays all sorts of games reformatting and “improving” the layout. One day I’ll find a way through this mess. I asked the question here on how […]

]]>Apologies in advance for the formatting of the code. WordPress is, basically, shit at handling any kind of formatting that is not its own flavour of HTML, so it plays all sorts of games reformatting and “improving” the layout. One day I’ll find a way through this mess.

The problem was that log files were being created by different OS users, depending on who was running Laravel (e.g. Apache user, cron user) and causing permissions problems. I am reproducing my answer here, as Laravel forums have a habit of being archived away as each new version is released.

So, here we go with the answer:

Okay, I think I have it now. It was quite a trek to find the answer. The result is that I have log files written by web access and by CLI under different names, looking like this:

They are created by different users, and so don’t result in permission issues when writing to the files.

These are the steps needed in L5.0. I expect traits could have been used here, but I’ve extended classes instead. The steps are:

Extend Illuminate\Foundation\Bootstrap\ConfigureLogging in my add, to add a new configureCustomHandler() handler method.

Override the $bootstrappers arrays in Illuminate\Foundation\Console\Kernel and Illuminate\Contracts\Http\Kernel to point to my overridden ConfigureLogging.

Set the “custom” logging method in app config.

In each of the steps that follow, I’ve tried to explain what is happening, and why. Laravel has a habit of moving things around quite often and changing how things work, so hopefully the explanations will help you to seek out what you will need to do when things move on and my steps are not quite right.

It is all in the App namespace, so no messing was needed in composer to extend autoloading. The custom method is a copy of the configureDailyHandler() method in the parent class, with php_sapi_name() inserted into the logfile name.

So this goes into app/Bootstrap/ConfigureLogging.php

Step two involves telling Laravel to use this overridden class during bootstrap. The base bootstrap classes are here:

All we have done in both cases is remove the Illuminate ConfigureLogging bootstrap class and put in our override.

Final step three. What we have done so far is add a custom logger that is a tweak on one of the built-on loggers. However, we are not yet using it. Everything so far continues to run as it normally does (at least, it should, if no mistakes have been made).

Our custom logger handler method is called configureCustomHandler() and that makes the logger method “custom”. We could call it what we like: method “foobar” would need a handler configureFoobarHandler(). Simple.

So in config/app.php we find an entry:

'log' =&amp;gt; 'daily',

That runs the configureDailyHandler(). Just change that entry to “custom”:

'log' =&amp;gt; 'custom',

And that’s it. The new custom log handler will be used, with the new log file names.

]]>https://academe.co.uk/2015/06/laravel-5-naming-logfiles-according-to-os-user/feed/0OmniPay Authorize.Net DPM Gatewayhttps://academe.co.uk/2015/05/omnipay-authorize-net-dpm-gateway/
https://academe.co.uk/2015/05/omnipay-authorize-net-dpm-gateway/#respondWed, 13 May 2015 10:02:35 +0000http://academe.co.uk/?p=1391In this short series I hope to provide some practical worked examples showing how to use the DPM extension of the OmniPay Authorize.Net gateway. I’ll run through what all those terms mean first. Authorize.Net Authorize.Net is a payment processor that can be used to take payments on websites. It does a lot more than simply […]

]]>In this short series I hope to provide some practical worked examples showing how to use the DPM extension of the OmniPay Authorize.Net gateway. I’ll run through what all those terms mean first.

Authorize.Net

Authorize.Net is a payment processor that can be used to take payments on websites. It does a lot more than simply take payments, such as scheduled payments and refunds, but we are just looking at payments here.

There are a few broad modes in which Authorize.Net can be used. They are:

AIM – Advanced Integration Method. This is a machine-to-machine API. Your site collects all the details from the user (where needed), including credit card details and sends it on to the AIM interface. It gets a response, then processes that response as appropriate. This mode provides access to most of the facilities within Authorize.Net. It does, however, have strict PCI ramifications. Because the end user’s credit card details pass through your server, there are very strict rules and accreditation that must be followed and applied for. Most small shops and businesses would want to avoid this on their own websites.

SIM – Server Integration Method. With this method you send the end user off to the Authorize.Net website to enter their credit card details. Your site never sees these details. You can send what contact details you already know about the user along to the SIM interface with the user, so they don’t have to fill out their details afresh. Some people don’t like this, because the branding on the SIM payment screen belongs to Authorize.Net Personally I don’t find going to a trusted payment gateway site to fill out my credit card details is a problem at all, but apparently many people perceive it to be a bad thing. PCI compliance is still relevant, but it is not as onerous as for AIM. Credit card details do not go through your site, but if your site has been hacked, then all bets are off – you really don’t know what is being captured when malware is installed.

DPM – Direct Post Method. This method works in a very similar way to SIM, but with the payment form on your own site instead of a an Authorize.Net site. This payment form can be branded entirely to your liking. The form is not posted back to your site, but instead posts to the the Authorize.Net DPM site. The DPM site then posts back to your site the result of the credit card authorisation, and your site handles that and informs the end user. If there are mistakes in the form that the user submitted, then Authorize.Net DPM will inform your site, pass it the current submitted form details and give your site the opportunity to re-present the form to the user so they can make corrections.

SIM is by far the easiest to implement, and is much safer for you than AIM. DPM is very similar to SIM, but requires more to be implemented on your site. The benefit of that is that you have full control of the style and branding across all the payment pages.

This article will focus on the DPM method of using Authorize.Net, as it is a fairly recent additional to OmniPay – the PHP library that attempts to normalise a multitude of different payment gateways. The Authorize.Net gateway, containing support for AIM, SIM and DPM, can be found here. There are at present few examples of how the DPM gateway can be used through OmniPay.

OmniPay

The OmniPay package from The PHP League, originally developed by Adrian Macneil, is a pluggable library that provides access to a wide range of payment gateways. It focuses on common requirements: authorisation, capturing payments, voiding authorisation, and a few other services. It’s aim is to provide a common and consistent way to handle the different payment gateways, so it is simple easier to switch between them.

OmniPay is a composer package, and support for each gateway is provided through a separate composer package.

OmniPay largely meets its objectives, but suffers a little from a lack of worked examples in the documentation. Even though the library aims to make the gateway use consistent, each gateway does tend to have its own foibles – they all do something that requires some special handling in the merchant application, and that requires additional plumbing around the gateway.

We are dealing here with version 2 of the OmniPay library. My hope is that version 3 (proposed for later in 2015) will look a little deeper into these exceptions to find some patterns that perhaps have not been recognised previously, and they could be handled within OmniPay to reduce the amount of exceptional plumbing required in the application.

Authorize.Net DPM

The Direct Post Method (DPM) was likely introduced in response to the rapid rise and popularity of Stripe. This gateway popularised the method of POSTing card and address details direct from the merchant site – the shop taking payment – to the payment gateway. This means the users stay on the merchant site when completing their credit car details, but the details are never posted back to your site.

While Stripe and some similar gateways use JavaScript to POST the form details to the gateway, making them AJAX, and never taking the user away from the site, Authorize.Net DPM is different. It works like this:

The merchant site presents a payment form to the user, including fields for the payee name, address and credit card details. Any number of details can be pre-filled, and the merchant site can decide which fields are shown, which can be changed, and which are hidden.

The payment form is completed by the user. When the user submits the form, it POSTs direct to Authorize.Net not the merchant site.

The user is handed over to Authorize.Net, but they don’t hang around for long. The supplied credit card details are checked and a decision is made on whether the payment or authorisation is approved.

Authorize.Net will perform a callback. It will directly POST the results of the authorisation to the merchant site. The POST will include the status, any errors, and the details of the form as submitted (minus the credit card details – the idea is never to send them to the merchant site).

The merchant site validates, stores and processes those results in the callback.

The merchant site callback handler then generates a HTML page, usually based on the results, and returns it to Authorize.Net. That page will then be sent by Authorize.Net to the user’s browser. The main purpose of that page will be to redirect the user back to the merchant site. So while most payment gateways will expect the callback to return a URL, which the gateway will send the user to, this gateway asks for a HTML page containing a meta refresh and/or a JavaScript redirect to send the user to the correct page of the merchant site.

When the user returns to the merchant site, they are informed of the result. If the result is an error, then the merchant site can re-present the user with the form they completed and display the error message, so the user can try again. If the payment was declined, then they are told so.

All processing of the transaction should hopefully have happened in the callback, and not left for when the user returns to the merchant site, because sometimes the user may not have made it back for one reason or another. Many Authorize.Net gateways do not do that – they send the user to a “success” or “fail” page, where the transaction is processed or not from there. Don’t fall into that trap, because it is not secure.

The next part in this series will introduce the sequence chart that an implementation needs to follow.

]]>https://academe.co.uk/2015/05/omnipay-authorize-net-dpm-gateway/feed/0SugarCRM Vector Logohttps://academe.co.uk/2014/10/sugarcrm-vector-logo/
https://academe.co.uk/2014/10/sugarcrm-vector-logo/#respondSat, 25 Oct 2014 13:25:09 +0000http://academe.co.uk/?p=1328I needed this for a talk, and could not find a vector logo anywhere. So I knocked one up and it would be rude not to share. All the workings are in the SVG (the traced bitmap and layers that may be useful) as well as the final vectors. Update August 2015 The logo I […]

]]>I needed this for a talk, and could not find a vector logo anywhere. So I knocked one up and it would be rude not to share. All the workings are in the SVG (the traced bitmap and layers that may be useful) as well as the final vectors.

Update August 2015

The logo I used had the SugarCRM stylised cube with the wording underneath. I have been contacted by SugarCRM to inform me that this is not the correct logo. The colours were out of date, and the logo has never been officially authorised for use with the wording under the cube.

So, I have removed the old logo from this page, and instead present the logo as authorised at this time. Again, I’ve passed it through Inkscape to do some tracing, as the original was just a bitmap. This is in no way an official vector trace, and I realise some of the corners need a little tweaking, so just treat it as something for personal use.

SugarCRM logo, transparent PNG for use on white background.

The SVG file can be downloaded using the link below. If your browser renders it, then use “Save Page As…” to save it to local storage.

]]>https://academe.co.uk/2014/10/great-sources-of-free-stock-photos/feed/0Watching things move around the worldhttps://academe.co.uk/2014/07/watching-things-move-around-the-world/
https://academe.co.uk/2014/07/watching-things-move-around-the-world/#respondWed, 09 Jul 2014 09:00:16 +0000http://academe.co.uk/?p=1293I have a few favourite sites that provide the ability to watch things moving or happening around the world, in real time. Here they are as a simple list, that I’m sure will grow (GPS satellites and the International Space Station – ISS – come to mind): Lightning Watch lightning strike as it happens. You […]

]]>I have a few favourite sites that provide the ability to watch things moving or happening around the world, in real time. Here they are as a simple list, that I’m sure will grow (GPS satellites and the International Space Station – ISS – come to mind):

Lightning

Watch lightning strike as it happens. You can also get involved by building your own lightning receiver and plugging it into the detection network.

Okay, this is not strictly about transport, but it is my favourite of the three. By bringing up the lightning and flight pages together, you can spot the flights that make a detour to avoid the rough journey.

If you want to get involved in triangulating the strikes by running a receiver, you can start right here. Participants get access to the raw data in exchange, so if meteorological research is your field, it may be an invaluable resource.

Planes In the Air (no snakes)

Planes tracked around the world, as they move. Zoom in and you can see just how fast they are moving:

]]>https://academe.co.uk/2014/07/watching-things-move-around-the-world/feed/0Error 500 on password protecting a directoryhttps://academe.co.uk/2014/05/error-500-on-password-protecting-a-directory/
https://academe.co.uk/2014/05/error-500-on-password-protecting-a-directory/#respondTue, 13 May 2014 09:17:04 +0000http://academe.co.uk/?p=1285I was recently using cPanel to password protect a directory on a website. It was all point-click, so should have been simple and just work, except it didn’t. After entering your login credentials, the server would return an error instead of giving you access to the directory contents: Error 500: Internal Server Error By password […]

]]>I was recently using cPanel to password protect a directory on a website. It was all point-click, so should have been simple and just work, except it didn’t. After entering your login credentials, the server would return an error instead of giving you access to the directory contents:

Error 500: Internal Server Error

By password protecting the directory, cPanel was adding this to .htaccess in the protected directory:

The problem was that cPanel was putting the password into a file that the apache process could not access. For whatever reason, the apache process could not read .htpasswds/public_html/protected-directory/passwd to check the credentials.

The fix was to move the password file to somewhere the apache file could access it. In this case, I put it into the web root:

/home/account-name/public_html/.passwd

I made it an “hidden” file by prefixing it with a “.” and this prevents it from being served up on the website. The AuthUserFile entry was set to point to this file:

AuthUserFile “/home/account-name/public_html/.passwd”

There will be other ways to solve the problem, other users running the httpd process and other security concerns to take into account, but making sure the password file can be read by the httpd process serving the site from account-name was the key.

]]>https://academe.co.uk/2014/05/error-500-on-password-protecting-a-directory/feed/0WooThemes’ Canvas – Main Responsive Menu in Side Barhttps://academe.co.uk/2014/04/woothemes-canvas-main-responsive-menu-in-side-bar/
https://academe.co.uk/2014/04/woothemes-canvas-main-responsive-menu-in-side-bar/#commentsMon, 07 Apr 2014 14:46:31 +0000http://academe.co.uk/?p=1235I really like the WooThemes Canvas theme, and use it a lot. It is a plain, but sophisticated WordPress theme on which to build a more specific child theme. The theme uses a horizontal menu at the top of the page for the primary menu. When the view port is narrow, such as when displayed […]

]]>I really like the WooThemes Canvas theme, and use it a lot. It is a plain, but sophisticated WordPress theme on which to build a more specific child theme.

The theme uses a horizontal menu at the top of the page for the primary menu. When the view port is narrow, such as when displayed on a mobile device, the primary menu collapses to a hidden menu that is accessed through a “pillar box” button.

This page viewed on a wide screen:

Primary menu shown on wide viewports

The same page on a mobile:

Primary menu shown on narrow viewports.

Now that is great, so long as your design requires the primary menu to be a horizontal menu. Some sites put the primary menu in one of the side bars, down the left or right of the content. Canvas does not support collapsing those menus in a responsive way to the top of a narrow display port.

Luckily, there is a simple trick to work around this. Instead of just one primary menu, we use two: one horizontal and one in the side-bar. For wider viewport sizes we show just the side-bar menu. For narrower viewport sizes we show just the horizontal menu. The menu appears in the source of the page twice, but that’s not at all a problem as they are generally very light.

The first step is to create your menu. Create a custom menu in WordPress and give it all the menu items you want. That menu is then used in two places: within the Canvas theme it is set as the Primary menu, and within your side-bar is it set as a widget menu.

The width of 767px is the cut-off point at which the site displays as a single column. This is defined within the Canvas core stylesheets. It would be great not to have to use the !important directive, but since Canvas has it liberally sprinkled throughout its stylesheets, it must be used here to add enough precedence to override the core style selectors.

Next the size menu is hidden when the page is narrow. This is an optional stage – if you don’t hide the side menu, then it will just appear beneath the content, which is not a big issue, unless it results in too much extra scrolling to get at some important links below the main menu in the side-bar.

In this example, I am using a standard WordPress menu widget, and it happens to be widget number two, so it gets the ID “nav_menu-2”. Your widget will likely have a different ID, so you will need to investigate in the page source. Do note, however, that this is the ID of the outermost wrapper around the menu. You do not want it to display as an empty box – you want the box hidden too.

]]>https://academe.co.uk/2014/04/woothemes-canvas-main-responsive-menu-in-side-bar/feed/4Removing Author Details from Posts in WooThemeshttps://academe.co.uk/2014/03/removing-author-details-from-posts-in-woothemes/
https://academe.co.uk/2014/03/removing-author-details-from-posts-in-woothemes/#commentsSun, 23 Mar 2014 15:07:40 +0000http://academe.co.uk/?p=1227Under each post in a WooThemes theme, is a box that provides details of the author. Some sites, especially business sites that just want to publish their own news items from time to time, do not want the author details appearing. So how do you remove it from a WooTheme? One method would be to […]

]]>Under each post in a WooThemes theme, is a box that provides details of the author. Some sites, especially business sites that just want to publish their own news items from time to time, do not want the author details appearing. So how do you remove it from a WooTheme?

One method would be to override the templates and remove it. However, every time you override a template, you are storing up problems for a future theme update, as your custom template and the core Woo template get further out of step. Instead, there are hooks that can be used.

Jumping straight in, this code, added to your child theme’s functions.php, will remove the author block from below each post:

The first uses the an anonymous function and the second a named function, but they essentially do the same thing.

In the wp_head action, WooThemes registers woo_author_box() in its woo_post_inside_after action at priority 10. We just need to remove woo_author_box() from that same action, and do it at priority 20 of the wp_head hook, to make sure we remove it *after* it was added.