In a post to his site Ben Sampson shows how to mask IDs in URLs using hashids in a Laravel-based application. Hashids converts values into strings that can then be decoded back to their original values.

By default a URL generated by a Laravel app will contain the ID of a model like this https://app.name/users/1 where 1 is the ID of the item. Often this is absolutely fine, but sometimes you might want to hide it (or obfuscate it). The two main use cases for this I've come across so far are: Security [and it looks] More professional.

He shows how to use this package to encode and decode ID values in your URLs. He also includes updates to the models, controllers and routing to use route model binding to handle the encode/decode process. He shows how to set up different salts for different data types, setting it on each model and how to correctly bind the functionality in the main route service provider.

In his latest post Anthony Ferarra makes a suggestion about teaching developers how to solve problems via a "quick fix" versus educating them about the real problem: educate, don't mediate.

Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about "The Dreaded eval(base64_decode()) - And how to protect your site and visitors" have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad. The problem is that these posts have been suggesting things like "Disable eval()" and "Disable base64_decode()" as possible solutions. And while technically that would work, it completely misses the point, and does nothing to protect users

He suggests that developers shouldn't just look for a "quick fix" solution posted in a tutorial somewhere and go on their merry way. One danger in this is that those instructions could only be patching part of the problem, not all of it. In this case, the disable eval/base64 handling is only a code-level fix. If this exploit exists in your application, the attacker was able to get to the local file system - a much bigger problem.

PHPBuilder.com has posted a new tutorial today showing you how to work with JSON in PHP including serialization and database interaction.

This article explains how to use the JavaScript Object Notation (JSON) extension in PHP, going step by step through a series of essential operations. JSON is an object string notation, it is defined as a subset of JavaScript's syntax and its general-purpose is to interchange data format. As you probably know, JSON was first made to be used with JavaScript for accessing remote data, but now it is used by many other languages because JSON data is platform independent data format. JSON can be used natively in JavaScript, but you can also use it in a server-client application logic.

They start with an introduction to the JSON structure and how to both create and encode data using PHP's own json_encode and json_decode. The examples start out using arrays for the data but then move into something slightly more complex - objects. The article talks about JsonSerializable and show how to automatically hook the data into a table and store the content based on the column name/property name match.

On PHPMaster.com today there's a new post from Abdullah Abouzekry showing you how to create QR codes (like these) with the help of a PHP library, PHP QR Code.

Used widely in various recent applications, QR Codes can be seen on cola cans, business cards, in sushi bars, and in museums. QR Code is a 2-dimensional barcode specification that was invented in Japan. [...] In this article I’ll show you how you can easily generate QR Codes from within your PHP application and share some ideas on how and when to use them, We’ll be using PHP QR Code, a library written in PHP for generating QR Codes and which doesn’t require any dependencies beyond the standard GD2 graphics extension for creating images.

Using the library makes things pretty easy - all you need to do is call the correct method related to the image type (like "png()" or "jpg()") for your desired output with the string you want to encode. You can also define things like the level of error correction of the result - related to how much data the image can store - and size.

Nicolas Grekas has submitted about a new tool he's developed to "represent faithfully any PHP variable as complex as it is" - Patchwork-Doc (related to his Patchwork PHP framework).

The JSON format on which it rests guarantees maximum interoperability while ensuring good readability. The implementation done in the JsonDumper class operates all potentialities of the representation while providing maximum latitude to the developer to exploit its ability as desired, both in term of exposure of internal class mechanism for specialization and in terms of custom use, thanks to the callbacks that allow to intercept the JSON line by line and to adjust the dumping of objects or resources according to their type.

It isn't required to use the framework to use this tool, however. You can see an example of the output format in this example on the project's github page, complete with a guide to some of the advantages and disadvantages of some of the current, more common methods of output. Several types are included in the example including simple string/integer values, objects, classes, stream resources and the results of variable casting.

David Stockton has a new post to his ZendTutorials.com site today introducing you to an increasingly more handy Zend Framework component that can make your messaging needs easier. The new tutorial introduces you to Zend_Json, a component for generating and parsing JSON messages.

In the past few years, JSON, or JavaScript Object Notation has seemed to overtake XML and other data encoding methods on the web. [...] I’ve also seen numerous examples of developers who create their own sort of JSON encoder rather than either using json_encode or using Zend_Json. What inevitably comes back to bite them is when the data they are encoding contains a special character like quotes, colons, curly brackets, etc.

He demonstrates how the Zend_Json component helps to alleviate some of the worries with built-in features that handle everything from basic encoding/decoding, printing out results in a "pretty" way and a handy way to include executable Javascript (once it's evaled on the other side) in your payload. He finishes the tutorial off with a mention of a very handy method that will please those already having to work with XML - the fromXML() method that automagically converts the data over to JSON for you.

In a recent post Marcus Bointon looks at a hashing method that's not one as commonly used by developers as the usual base64 - base-62 encoding that plays a bit nicer with things like URLs and emails due to the character set it allows.

There's a really horrible bug (though they won't call it that!) in Apache's mod_rewrite that means that urlencoded inputs in rewrites get unescaped in their transformation to output patterns. The bug actually remains unfixed, though a workaround first appeared in Apache 2.2.12. [...] Base-62 is interesting as it can be made safe for use in URLs, DNS, email addresses and pathnames, unlike any available encoding of base-64, as it only includes [0-9A-Za-z].

He originally wrote his own parser, but notes that now the BCMath and gmp extensions make it much simpler, just a call to gmp_strval with gmp_init. This method works, but it's still not quite all he wanted so he created his own encoder to do the job.

Lorna Mitchell has a quick reminder about an issue in the new joind.in API version - everything was being returned as strings, even integers.

A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.

This option, JSON_NUMERIC_CHECK, tells the json_encode function to property consider numbers in its encoding process. It applies globally, so if there's an instance where you don't want something assigned as a number, you might need to go with another, more flexible JSON encoding option. You can find information about this and other possible options json_encode can take on its manual page.

In a new post to his blog Johannes Schluter looks at a helpful new inclusion into the latest versions of the PHP trunk - a new JSON serialization interface included in the core.

For many PHP objects the JSON-representation of the data is a bit more complex.for instance what about private properties or maybe you want to calculate some inner values? - In PHP 5.3 you were on your own. but thanks to Sara there's hope in sight: the new interface JsonSerializable. Classes implementing this interface have to provide a method jsonSerialize() which will be called by json_encode() and has to return a JSON-compatible representation of the data by doing whatever you want.

He gives two examples of this new feature in action - a simple one that just spits out some basic JSON as a result of the output of a class and the other that's a bit more technical, involving multiple class isntances, a stdClass and a normal array.

Evert Pot came across something strange in an application he was working with - the incorrect decoding of data coming back from an Ajax call POSTed back into the app.

Basically, data is coming into our PHP application through a Javascript's XMLHttpRequest (ajax). [...] Normally everything in the $_POST and $_GET arrays is already decoded, so when you're dealing with these arrays you don't really have to think about this. This time however, I was dealing with some non-latin unicode characters and for some reason they were never decoded and ended up in the database as raw url-encoded strings.

The issue was caused by the fact that the non-latin characters were handled differently on the byte level and that, because of the choice PHP makes on which of the unicode characters to use for spaces, he found that there were two options for handling strings - escape() and encodeURI().