Securit:ee Blog Archive
mithra62 on GitHub
Today, I'm following the lead set out by Solspace and Exp:resso (among others) and releasing a bunch of goodies onto GitHub. I love the idea of making things easier and fun for users and developers and GitHub is a great place to do that.
First, all mithra62 add-ons that have language packs now have those language packs available on GitHub. This includes Backup Pro, Backup Pro(ish), CT Admin, Export It, Automat:ee, Securit:ee, and Flag Master. If you have any translations for those add-ons please do a pull request to make them available to the community. Oh, and all translators will receive a free license for the add-on they've translated once it's been officially merged with the repository so get on that multilingual EE people.
Next, with the exception of Backup Pro(ish), I've put the "free" add-ons onto GitHub. Right now, this includes EE Syntax and Meetup though any new free add-ons will be on GitHub as well. The only exception will be add-ons, like Backup Pro(ish), that are loss leaders and released to build awareness in another product. It just doesn't make sense to release add-ons like those on GitHub.
Hit me up if you have any questions or concerns.
A Year of Add-on Developer Licenses
One of the first requests I received since releasing Backup Pro a year ago last June was for a developer license (1 price/unlimited installations). Truth be told, I was adamantly against it. At the time I thought it was a just silly idea and I'd lose money in the long term for sure. But, due in no small part to the persuasiveness of the ExpressionEngine community, I obviously came around and released Backup Pro Developer last October. Now that it's been a year, and I've been able to see things first hand, I'm going to be making some changes and I wanted to go over the details and my thought process when deciding if they were right for me.TLDR: I'm going to no longer offer developer licenses on my add-ons starting today and below is why. Anywho...
When I was first asked to release a developer license of Backup Pro, back in, I think, August 2011, I really didn't like the idea. It just seemed short sighted; a trade of short term gains over long term stability. It seemed to me that, at the time, the ExpressionEngine market just wasn't large enough to support the model. Too few available customers to offset the potential interest. Basically, the number of new, and available, customers wasn't growing fast enough to replace those potential sales lost through repeat purchases (yes, I may make more today, but I'm going to make less tomorrow). Not a good strategy for longevity. Nope; no way was I going to do developer licenses thankyouverymuch.
But then I made a colossal blunder; I started to think about piracy. And I realized our piracy prevention options do not exist. Within the ExpressionEngine add-on market there's a great deal of trust between the developers and the customers.
Code obfuscation is an abomination of an idea. A black hole of despair for any customer that is, in my experience, forced on developers by business pretenders who want to look useful. There is no good reason to do this and pretty much all add-on developers get this. Preventing perusal, extension, and/or modification of the underlying code is contrary and even anathema to every add-on developer I know; in fact, the exact opposite ethos of ExpressionEngine itself. Plus, it's ridiculously easy to reverse any encoding so It just makes no sense from a prevention or technical standpoint.
Were we to employ DRM within our add-ons, we would be repeating the mistakes of, well, pretty much the entire entertainment industry, and almost all of the existing commercial software industry. Industries that have spent billions of dollars to effectively treat all customers as criminals. I'm sure we've all seen or experienced firsthand the frustration DRM can cause on legitimate use so please, for the love of God, let us never employ DRM within the ExpressionEngine add-on market.
Even simple license key verification isn't done. And, again, this is a good thing. Even though license verification isn't, at the core, similar to DRM, it does present a couple issues for customers similar to DRM. For one thing, verification is traditionally done using a remote service that requires constant and responsive up time. If the remote service isn't running at 100% performance and efficiency, 100% of the time, it can lead to a degraded user experience for the customer in certain circumstances. To do properly, to avoid this type of situation, just isn't something to be taken lightly. Thankfully, I know of no one who does this and I'm glad for it (outside of add-ons where a remote service is the core of their functionality of course).
So, to me, it all comes down to trust. We're trusting our customers and, in theory, treating them with respect. We're trusting that the customer isn't going to ignore our license agreements. We're trusting that they won't do the easiest thing in the world, and just copy/paste our add-on between sites. We're trusting that customers won't download our add-ons from those pirate sites that pop up from time to time. And we're trusting our customers to not use one of the myriad of Dropboxes that are out there that contain our add-ons (yes, we know they exist and mostly don't care). For this, we add-on developer treat our customers with respect and not cripple or cause degraded experiences when using our add-ons and/or, for most, when asking for support.
And this is how it should be.
But I'm a cynical sumbitch'. While I agree that we shouldn't do anything to hurt user experience or treat our customers as criminals I just couldn't get past the idea of trusting customers 100% (not you who are reading this though; you're cool). As much as I like to think of myself as a forward thinking developer who doesn't care about piracy the truth is that it does concern me; just not enough to take it out on the customer. I mean, let's be honest; It's not exactly a simple process to purchase add-ons when compared to the ease and use of piracy. Seriously people, copy/paste for crying out loud...
Once I realized that is when I started to seriously consider developer licenses. Why not take it off the table? What if, for a moment, the ease and convenience of piracy was taken off the table? It seemed possible to make things easy on customers and still profit. I mean, you'll never stop deliberate piracy, best leave that alone, but the unintentional kind? Sure, why not make it a non issue?
And by "unintentional piracy" I mean the type of activity where a customer wouldn't pay for a license is essentially an accident. An oversight. For example, the customer does some prelim prototyping, they grab a copy of the add-on from an old site to test on (fully intending to buy a license if things move forward), and then things progress and they forget. With the way that I personally work, this seemed highly likely. As I said, I just want to code, and I do lots of prototyping. I try to remember to make things right, now more than ever, but paying for a license has slipped my mind from time to time. Me, not being a unique snowflake, it makes sense that others would work in a similar fashion.
There's also the whole, "Start a project before assets have been payed for" method of development that happens from time to time. Personally, not a big fan, but, yeah sure, whatever, it does happen occasionally. Let's not pretend it doesn't. Point though is that once things get underway it'd be an easy and forgivable oversight to forget to pay for the add-ons. It's not like they're intentionally trying to be a dick; just that, again, the convenience of copy/paste is pretty great.
Plus, it seems pretty obvious that developer licenses are, overall, a good thing for customers and it is important to be good to your customers. Not that they're not without their problems but, by and large, it's a tough argument to make that developer licenses aren't good for customers. Right?
Outside of the obvious cost savings (1 price for unlimited is tough to beat from a consumer standpoint), they make licensing a breeze. No longer does a customer even have to think about researching an alternative product, purchasing that product, learning about that product or maintaining any add-on licenses. Having personally dealt with this, to me, it sucks. I want to spend my days with my head in code, so anything that distracts me from that goal just bums me right the fuck out. Plus, there are only 24 hours in a day and us web developers are some busy people. One less thing is a good thing.
Another, and likely most important, is that when a customer purchases and add-on developer license they've made their choice. This stuff's hard, and developer licenses allow customers to put their trust in 1 company for 1 or more aspects of their site. When a customer purchases a developer license of a product, that customer is effectively saying that they trust that one product to handle that aspect of all their client sites. It also means that the customer knows the product well enough for that level of trust; they've figured things out and know the little peccadilloes of a given product and they still love it. It's no wonder that customers of developer licenses require far less support than your average customer.
The only, and relatively small, complicated part of the equation is what to do when a client leaves a development shop that has a developer license. How do updates and upgrades happen for the client? For me, I admit, the solution is pretty crappy; hit me up with the developer license key for the product, the devot:ee account name of the client, and I'll gift the account a license so they can stay updated. Not exactly an ideal solution but it's easiest on everyone else I think...
But, are developer licenses good for add-on developers? With a few exceptions, and definitely depending on the circumstances, not so much, in my opinion. Don't get me wrong, there are definite upsides, and depending on a developers long term goals, they can even be a good thing. But if I knew a year ago what I know now, I probably would have passed on the whole idea.
First though, in certain circumstances developer licenses can be good for the developer. Absolutely. If a developer is doing add-on work as a side gig, with no expectation or plan to go full time, they can be a nice and easy way to randomly increase revenue in chunks rather than organically over time. Developer licenses are real good at doing that. If you're ok with having income that fluctuates heavily month to month, I think you'll find developer versions of your product to be a nice addition.
Another school of thought is that it really does depend on the add-on. An add-on like Backup Pro, that required hundreds of hours to perfect, and over a hundred hours in support, does not. It's sort of embarrassing in hindsight, but yeah, an add-on that requires this level of investment should never have been sold with a developer license. Were it an add-on that was simply developed and released at 1.0 or grew slowly and required little to no further time investments, now that would make a little more sense for a developer license.
Had I not released EE Syntax as GPL, now THAT would be a prime candidate add-on for a developer license. That was a nice and simple add-on that never really got past the 1.0 stage of it's life.
But, by and large, and for me specifically, developer licenses don't really make much sense. Backup Pro, Automat:ee, and Securit:ee are all really complicated products that require serious time investment. Yes, even now. Frankly, if that time can't be financed it's no longer worth investing in those products, and I should retire them. It's just bad business and this is the writing on the wall from the above chart.
Now, don't get me wrong, I love those peaks; there are very few things that a dramatic increase in revenue can stymie. It's the valley's that are a problem. In order for me to do ExpressionEngine add-on development as my primary source of income (which is my goal with mithra62), things have to stabilize and/or grow quite a bit. Growth in ExpressionEngine add-on customers is slow coming so the choice is pretty much made for me.
In the above graph (which, BTW, is taken from CT Admin and illustrates the progress of Backup Pro since the initial 1.0 release), note the increase at October 2011. That's when I first released Backup Pro Developer. As you can see, things definitely spiked upward after the Developer version was released and then took a distinct dive on a month where no developer licenses were purchased (April 2012). Then up again, then down. Again. It's become inconsistent. It makes much more sense to focus on building a consistent revenue stream especially though because it's crazy important that revenue is able to be anticipated.
So we have one of those moments where something that's good for the customer is actually bad for this developer. Which is my long and detailed way of saying that, unfortunately, I'm going to no longer have available the developer licenses for any of my ExpressionEngine add-ons starting sometime soon. (There are some logistics to be worked out first but I will make an announcement.)
Now, if you've already purchased a developer license of one of my add-ons, don't worry. Nothing is going to change for you. You'll still be able to download the add-ons and never have to purchase a new license or anything like that. This only applies to any customers looking to purchase a new developer license.
I know this may come as a shock to a lot of customers, that I would be against developer licenses now, but I really do think the market isn't large enough to sustain them just yet. Maybe, in the future, I'll revisit things and come to a different conclusion, but, for now, developer licenses are just not worth it.
Securit:ee 1.3.3 Released
Today marks the final feature entry for the Securit:ee 1.3 branch with the release of Securit:ee 1.3.3. From this point forward, any new additions to this branch will likely be bug fixes. That is until 1.4 when new features are added.
This release adds in FreeForm Pro, Matrix, and Zenbu support to the Encryption FieldType. For FreeForm, you can add the Encryption FieldType to your FreeForm Pro forms. The Matrix support allows you to add the Encryption FieldType to your Matrix fields. The Zenbu integration allows you to setup the Encryption FieldType inside custom views for your Channels. All rules and settings are applied so things stay secure.
Be sure to check out the Change Log for complete details on what's changed.
You can get the update to Securit:ee from either Devot:ee or CartThrob.com.
Securit:ee 1.3.2 Released
Securit:ee gets another update today to 1.3.2 today. Along with the normal round of bug fixes, there are new scan vectors for the security scanner and a new template tag ({allow_ip_form}) for allowing IPs into the system.
Now when someone is blocked by the IP Locker they'll be directed to a form where, if they're a part of the allowed "add" groups (which is configurable), they can request an email to confirm their identity. The form tag works just like the other Securit:ee form template tags so it should be simple to get up and going.
You can get the update to Securit:ee from either Devot:ee or CartThrob.com.
Why You Should Care About Securit:ee
Yesterday marked the biggest update to Securit:ee since it's creation over a year ago. With that in mind, I'd like to go over why every ExpressionEngine site should have it installed and what it can do for you and your clients.
First though, let me say that I'd previously decided not to ever "push" Securit:ee because of the fear of creating FUD and just coming off as slimy. I know I'd personally be skeptical of someone outlining a problem I didn't know existed who also, magically, has the solution. But after discussing Securit:ee with a friend over the weekend I've come to realize it's necessary to go over the particulars of what Securit:ee does and how it can protect your ExpressionEngine site. Still, if you have any doubt, hell, even if you don't, please do your own research. Security is something every developer needs to think about all the time with every project they build and maintain.
That said, I'd like to drill this into every web developers brain; there is NO SUCH THING AS A SECURE SITE. A "secure" site is a myth. They don't exist. The closest you can get would be if you had a completely static HTML site that didn't use a web server, JavaScript, any database, or programming language that wasn't connected to the Internet and only accessed from a dumb terminal with no external media ports. And even then, if someone wanted to gain access and they had enough perseverance it's absolutely, 100%, possible. Claiming anything is "secure" is hyperbole at the highest level and anyone who claims otherwise is, frankly, making shit up.
With that in mind, there appears to be a popular opinion surrounding ExpressionEngine that all the security you need is built right into the core. Nothing could be further from the truth. Yes, ExpressionEngine goes to great lengths to provide protection against your tried and true security issues (more than any other CMS I've worked with). SQL Injection, CSRF, Remote File Inclusion, path traversal, and session hijacking are all taken into account and there are safeguards protecting a site against these types of attacks. Further, there are many configuration options available to add even more security safe guards, like login lockout, complex password requirements, XSS filtering of file uploads (though due to a long standing bug with PDF file uploads, ExpressionEngine recommends disabling XSS filtering though YOU SHOULDN'T).
And it's a good start. But that's all it is; a start. Security is an ongoing practice that doesn't stop at just those specific attack vectors and configuration values.
More, a web site isn't just ExpressionEngine (or WordPress or Joomla or any of the dozens of other CMS's available). There's the web server software (Apache), the database (MySQL), the programming language (PHP), and this is where a great many exploits come in, the myriad of programs installed on the physical server as a part of the Operating System (Linux). And before anyone think's the likelihood is minimal know that I've personally had a site compromised for running CUPS (the Linux print system). Is the site on a shared host? Then you're also at the mercy of every other site and security vulnerability within those sites (depending on how the shared hosting server is secured and setup).
These are very real concerns all web developers should be thinking about all the freaking time.
This is where Securit:ee comes in. The design for Securit:ee is built with a concept called Defense in Depth in mind to augment a site with various components designed with both preventing a site from being compromised and keeping damage to a minimum if, and when, it does become compromised.
There's the File Monitor which alerts ExpressionEngine site administrators when there are changes, and what files, to their file system. Why? Because when a site becomes compromised there are unexpected changes to the file system. This way administrators know when somethings going wrong with their site. Notice a change you don't recognize? Investigate and possibly lock down the site to prevent further destruction.
There are 2 IP Lockers; a Control Panel IP Locker and Client Side IP Locker. The IP Lockers are useful to ensure access to your site's Control Panel or Client Side only comes from authorized locations. Locking down the Control Panel is obvious, but the Client Side IP Locker is useful for when your site gets compromised. Likely the quickest way to stop an attacker would be to lock it down while your investigation is under way.
The Control Panel Login Alert is designed to send an email to whoever you setup whenever someone logs into the ExpressionEngine control panel. Why? So that a site administrator can know if, and when, an unauthorized access is happening. For example, if an attacker were to compromise an account and log into the Control Panel. Notice an unauthorized login from somewhere you don't recognize? Investigate.
The Security Scanner looks at your site and server's configuration and lets you know what to change and why. It looks at your ExpressionEngine config, your PHP setup, how your Control Panel is setup, and will even look for any cruft left over from your Version Control System (you're using one right?).
The Encryption FieldType allows you to store sensitive data in a safe and secure way. When setting it up per channel you configure what Member Groups can view the data so only those who need to view things can view things. If a user views any Channel Entries with encrypted data who shouldn't view the plain (unencrypted) data they're presented with a placeholder that you set (***** by default though it's configurable) . This is great for if, and when, your database becomes compromised.
The Forgot Password tag replaces the default ExpressionEngine Forgot Password tag that simply resets a member's password and sends it in plain text. There is NO good excuse for simply resetting a password and emailing it. Sending a password in plain text is incredibly insecure because the majoriy of website members will simply leave the password in their inbox ready for the picking. Instead, the Securit:ee Forgot Password tag sends an expiring link that directs users to set their own password. You have complete control over the email message and link expiration times so you can customize things to fit your specific needs.
Then there's the Member Group Expire. This is especially useful for when dealing with tech support and allowing temporary access to your site. Essentially, you assign Member Groups to expire and the account automatically disables itself after the time you set thus preventing support accounts from remaining active over time.
There are other modules and extensions in Securit:ee (Expiring Passwords, CP Registration Email, etc) that are all geared towards making for a secure and safe ExpressionEngine site.
BTW, if you've been following along closely you'll have hopefully noticed a trend. There's no doubt in my mind that every site will be compromised. Every. Site. To think otherwise is to set yourself up for failure of the highest level in web development. This is what separates the amateurs from the professionals. If you take 1 thing away from this take this; if you're not paranoid about your site's security you WILL have a crazy bad day that will stick with you for the rest of your career.
Securit:ee is available for sale on either Devot:ee or CartThrob.com.
Securit:ee 1.3.1 Released
This release of Securit:ee to 1.3.1 adds a good deal of polish and additional features to add additional security to your ExpressionEngine sites. Added Member Group Expire, Password Expire, CP Member Registration Email Notifications, AJAX usage for Forgot Password and Change Password, and lots, lots, more. Be sure to check out the Change Log for complete details.
You can purchase Securit:ee from either Devot:ee or CartThrob.com.
Securit:ee 1.3 Released Today
Today's release of Securit:ee 1.3 adds in some much needed improvements to ExpressionEngine sites. There's a complete reworking of the Forgot Password template tags, a new Change Password template tag, Safecracker support for the Encryption Fieldtype, and updates to the Security Scanner.
The default Forgot Password within ExpressionEngine has long been a source of disappointment to many security minded devs. By default, when a user forgot their password ExpressionEngine would reset their password to a random string and email the password to the user. This method is fraught with failure and just bad practices. Securit:ee 1.3 fixes this by adding in a new tag (exp:securitee:forgot_password) that doesn't change anything without further action. Instead, an expiring link (24 hours) is sent to the user that, when clicked, will send users to a form to change their password. The tag can use either inline or the default (gross) ExpressionEngine error messages.
There's also a new stand alone change password template tag (exp:securitee:change_password) which allows logged in users to update their password without having to enter in their username. If a user is not logged in then the tag requires there be a valid forgot password hash in the URL otherwise the user is free to change by just visiting the page. It uses the built in ExpressionEngine password rules for validation and inline error messages.
The Encryption Fieldtype also gets an update in that it is now fully Safecracker compatible for use outside the Control Panel. Now you can ensure data is not only consumable on the front site (as always) but also displayed using secure practices so your data remains a secret if needed.
The Security Scanner, to let you know suggested improvements to your ExpressionEngine site, has also been updated to remind to configure Securit:ee properly and also to recommend certain add-ons to install like the Devot:ee Monitor and VZ Bad Behavior.
You can purchase Securit:ee from either Devot:ee or CartThrob.com.
Securit:ee 1.2.1 Released
Securit:ee 1.2.1 adds a new feature to Securit:ee; the CP Quick Deny. The CP Quick Deny allows Super Admins the ability to lock down their Control Panel to remove specific member groups from accessing things.
Hit up Devot:ee to download the update.
Securit:ee 1.2 Released
Today's release of Securit:ee 1.2 brings additional checks to the Security Scanner, Help Tab documentation support, and the new Encryption Fieldtype.
The Encryption Fieldtype allows Channel Entries and Safecracker form to save data in an encrypted state so sensitive data won't be easily viewable. It's pretty configurable, allowing you to set who can and can not view the raw, unencrypted, value along with the "stand in" text if a user can't view the value.
Hit up Devot:ee to download the update.
Now With Improved Docs
Compared to the first weeks' HUGE amount of output (site launch, Backup Pro 1.8, Backup Pro(ish) and Backup Pro Developer) last week appears to have been a wash. Unless you've been paying close attention tt just looks that way. Last week had a bunch of small but needed improvements to this site along with a bunch of prep work in terms of new add-ons. Plus, lots of support requests and the fucking lawyers stealing my joy (and charging me for the pleasure).
In terms of site updates, there have been some really nice improvements to the add-on documentation as well as add-on main pages. First, the documentation has been updated for all add-ons to improve the formatting and readability. This actually led to a new add-on to be released this week for syntax highlighting (more on this below) that's released under the GPL. There's also improved galleries for the individual add-on pages with a couple bug fixes people experienced in Safari (which is pretty much everyone who cares about ExpressionEngine it turns out).
This week I'm planning on releasing EE-Syntax (the syntax highlighter mentioned above) and an update to Securit:ee that includes a new field type for encrypting and decrypting data.
EE-Syntax is to be released as a GPL licensed add-on and is a pretty direct port of one of my most used WordPress plugins WP-Syntax (hence the GPL license). Still, it should help ease the pain of other WordPress developers making the transition to ExpressionEngine so I'm pretty excited about releasing it. In fact, a lot of work went in to ensuring the two work identically so any existing WordPress blogs that used WP-Syntax shouldn't need any updates; something that's always good IMHO.
This is gonna be a good week.
Enjoyed this Post? Share it!
Share on Facebook Tweet This!