Giter Club home page Giter Club logo

hashid_field's Introduction

Hashid Field

Enables you to add a unique and read-only hash to an entry, generated using the entry ID. Ideal for using as an obfuscated URL slug or non-sequential ID. This extension uses the Hashids library.

Code Climate

Installation and usage

  1. Upload the hashid_field folder to your Symphony /extensions folder.
  2. Enable it by selecting Hashid Field in the Extensions list, choose Enable from the "With Selected…" dropdown, then click Apply.
  3. Add to any section where you need a hash!

The field requires no interaction from the end-user as it automatically populates when the entry is created.

Hashes are regenereated when a pre-existing entry is saved, so if you change the salt or hash length and update an entry, its hash will change (otherwise it will remain the same). So it's generally advised to set-and-forget unless that's your intention. This is especially important if you plan on using the hashes for URL slugs. The field will warn the user if the hash is going to regenerate.

You can also regenerate Hashid fields via the 'With selected' toggle on the publish page. This works under the same conditions as above.

The minimum hash length and the salt can be set for each instance of the hashid field, and you can set defaults in your Symphony preferences.

Hash salt

Your sitename is used as the default salt when the extension is installed. If your hashes are to be used for any obfuscation purposes then ensure that your salt is as random/chaotic as possible, as two sites using the same salt will share hash values for the same corresponding entry IDs.

Hash length

The default hash length is set to 5 when the extension is installed. This is sufficient for the vast majority of cases, and you're highly unlikely to hit the unique limit in a single section. The field supports up to 32 characters, lengths set above 32 will be truncated.

How to's

Using the hash for URL obfuscation

This ones easy; just set a 'hashid' parameter on your page and filter by your hashid field in the datasource.

Using the hash for ID obfuscation in events

There are a few ways of using the hashid with events, but my preferred method is to use the hash in place of the entry ID. i.e.

<input type="text" name="id" value="{section/entry/hashid_field}" />

Then you just have to swap this out for your entry ID in your __trigger function in the relevant event:

protected function __trigger()
{
    // If the ID isn't a number then it's a hash, so convert it to the entry ID
    if( isset($_POST['id']) && !is_numeric($_POST['id']) )
    {
        require_once EXTENSIONS . '/hashid_field/vendor/autoload.php';

        $hash = new \Hashids\Hashids( 'TheSaltForThisField' , 6 );
        $decode_array = $hash->decode($_POST['id']);
        $_POST['id'] = $decode_array[0];
    };

    return $result;
}

Where 'TheSaltForThisField' and 6 are your hash salt and hash length. These need to be manually set in the event and are static values.

hashid_field's People

Contributors

beaubbe avatar chobohub avatar jurajkapsz avatar michael-e avatar nathanhornby avatar nitriques avatar wdebusschere avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

hashid_field's Issues

Delete field db entry before inserting it (frontend)

Not sure if this is actually required, but it fixed a problem on a site I'm working on and seems consistent with how other fields populate the db (DELETE then INSERT), I assume to avoid potential duplication issues, although that seems crude?

Version 1.0

Stuff for proper release. Not far off, just some formalities.

  • Validate hash length settings (field and /preferences) to prevent anything higher than 32 that's not a number.
  • Change default settings layout in /preferences to two column.
  • Ensure there's no redundant code.
  • Ensure code is consistent and squeaky clean.
  • Check extensions compatibility with older versions of Symphony.
  • TEST

Incidentally 32 characters is a relatively arbitrary limit for the hash. It seems to me to be plenty high enough to ensure a wide variety of uses. If anyone thinks a different upper limit would be better I'm all ears.

Field gets registered multiple times

In a Reflection Field discussion @brendo and me found out that the way the Reflection Field gets registered has big issues. The field may get registered multiple times, which is really bad for performance.

The Hashid Field is using the same logic to register the field (and has the same problems). I will send a pull request shortly.

1.1 Release

  • Add a 'With selected' option for regenerating hashes
  • Include the hash salt and length in the XML output. Could be of use to anyone wishing to do anything advanced with the field.

Implementation logic improvement

I don't really get the point of the current implementation of processRawFieldData and compile.

  1. processRawFieldData will actually save data (if not empty).
  2. compilewill only compile (and insert to the DB) if there is no data.

This means that you could POST a hash which wouldn't get overridden by the compile function.

I would expect the compile function to always do the work. To achieve this, processRawFieldData could return an array with a null value, and the compile function could do a Symphony::Database()->update instead of a Symphony::Database()->insert. (This is the way the Reflection Field does it.)

If you want this to be changed, I could send a pull request. But maybe the above is intended?

Version 1.2

  • Bring more structure to the readme.
  • Scale back styling.

TBC

New hash already displayed on entry before save

When a new hash needs to be generated (i.e. after changing the salt or length) the new hash is displayed before save, this should be the old hash until the entry is actually saved and the hash changed.

Hashid not updated when entry is edited from the frontend

At the moment, the Hashid is saved/updated:

  • when an entry is created or edited in the backend
  • when an entry is created from the frontend

It is not updated, however, when the entry is edited from the frontend.

This is a conceptual flaw which can also be seen in the reflection field (and probably is has been taken from there). The idea of "registering" a field in the checkPostFieldData function doesn't work as expected, because Symphony won't call this function for fields that are not included in the POST data.

I will try and fix this together with #28 (if @nitriques gives his OK, see my question in c4ad03a#commitcomment-15529561).

Symphony fatal error when saving field settings

On 2.6.7, when adding a hashid field to a section, or changing the settings of an existing hashid field, upon hitting 'Save changes', I get the following error:

Symphony Fatal Database Error:
Field 'size' doesn't have a default value

An error occurred while attempting to execute the following query
INSERT INTO `sym_fields_hashid_field` (`field_id`, `length`, `salt`) VALUES ('78', '5', 'Symphony')

Despite this, the field works as expected in both the backend and frontend.

Entry needs to exist to have the ID to hash

Currently the hash will display when the entry is created, but the hash hasn't yet been saved as the entry didn't have an ID when the entry was created.

Chicken and egg that needs solving.

Bring clarity and polish to front-end

  • Display the hash itself as plain text in the section.
  • Improve the appearance of the field in the section to include a warning that the hash will change on save (when relevant).
  • When creating a new entry display a message that states the hash will be generated on save.

Create hash via event

The event side of this issue needs dealing with: #2

And events in general need testing etc.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.