It's important to understand... big or small, you are no exception to this exploit. If for no other reason, your site will be hacked to have a backdoor installed. You'd never even know about it until something very bad happens. You may find your private data (or even worse... your customers' data) posted somewhere on the public web. Your site may be used to launch attacks against other sites (e.g. DDOS). Your computer and/or server(s) may be taken over and used for their computing resources (e.g. cryptocurrency mining). You may find your site displaying offensive material. The list of really bad things goes on and on.
Why are Thinkbean clients already protected from this security vulnerability (as well as from
Drupalgeddon 1.0) - even before it was made public knowledge? Because where and how your Drupal installation is hosted is one of the major
factors in determining your vulnerability to this exploit. Thinkbean hosts its clients' sites only with the very few, very select, Drupal-centric hosting providers which have proven
histories of proactively protecting Drupal sites from this and other major security vulnerabilities.
There are plenty of
cheap hosting providers that offer "Drupal" hosting solutions. We've evaluated those solutions in practice and we would never trust a
client's site to them. Our hosting solutions are specifically optimized for Drupal installations
and absolutely customized to fit a particular client's requirements. Whether it's HIPAA compliance, e-commerce, 3D rendering, a
combination of all three, etc., our clients pay only for what they need... and nothing they don't. Plus, they appreciate a single
point-of-contact for their Drupal installation needs.
More
about hosting
If you are not on a protected platform (and there aren't many), it is critical developers perform the security updates within hours of their releases. Our security update process involves senior Drupal developers who thoroughly understand the current state of your website, the maintenance and update needs of your site relative to security concerns, and then implementing changes in a methodical process using a multi-tier release workflow, which minimizes downtime and ensures your live site is secure.
You can't just push a button and - Presto! - the update is done. Most Drupal sites are built on Drupal for a reason... they are mission-critical applications with many moving parts and have, at least, some degree of customization. One little update could easily break (or take down) your site! Drupal site owners can't risk the "try it and see what happens" approach. Trust only your certified, expert Drupal developer to properly perform the updates required to keep your business' most important asset running smoothly.
Here are some of the major takeaways:
Sadly, we often on-board new clients who are completely unaware they are hacked until we perform our site audit. The resultant exposure causes cascading effects which could be and should be avoided. Our objective and thorough auditing process ensures you'll never be one of those cases.
It is difficult (in the extreme) to re-gain a customer's faith, once lost. Compromised sites which expose confidential data have a massive, up-hill battle to win back their customer base. Don't let it happen to you... especially because it doesn't have to if you employ an expert Drupal development company. Drupal-centric hosting with built-in immunity from Drupalgeddon 1.0, 2.0, etc. is not nearly as costly as you might imagine. Working with Thinkbean's team of enthusiastic, highly-dedicated and certified Drupal experts has myriad advantages. You focus on your business. Let us focus on your Drupal installation.
When developing an API which has users with different roles accessing the data, there’s often properties which should only be accessible to privileged users.
I’ve written about how to restrict properties, by adding serialization groups to each property, but now we need to set the serialization context based on the current user.
Postman started out as an API development tool, but has developed more into, as they put it, an “API Development Environment”.
An over-simplified description is it allows you to create and save requests to test your API. You can then save your requests as a collection and share or publish them for others to use.
API Platform makes it easy to deliver all properties of an entity, but what about when you want to limit what properties are accessible to either GET or POST/PUT operations?
It’s surprisingly an easy bit of configuration.
What about dynamically limiting access to properties based on something like the user’s role?
This requires creating a service class, but it is still very approachable.
This article will cover:
