Sammlung von Newsfeeds | PC Service Boris Böhne Sindelfingen - Hardware, Service, Drupal, Hosting

Zivtech: How to Prevent Your Server from Getting Hacked

Planet Drupal - 1. Mai 2018 - 11:00

When coming up with a security plan for your Drupal website, or any website for that matter, you need to take several key factors into account. These key factors include your server host, server configuration, and authorized users. Typically, the weakest link in that chain is how your authorized users access the server, so first we want to secure access to allow your admins and developers in, but keep hackers out.

Hosting Provider

Choosing your hosting provider is one of the most important decisions to make when it comes to site security. Your server is your first line of defense. Not all hosts have the options that you need to implement best practices for securing the server itself, let alone websites or other services that will be running on it too. 

At Zivtech, we use VPS servers for some hosting solutions for our clients, but we also use specialized hosting solutions such as Pantheon and Acquia when it makes sense. Taking the time to figure out which services your site(s) needs prior to moving to a host will save time later; you won’t need to move to another when you realize they don’t provide the services you really need. It’s the concept of “measure twice and cut once.”

Authorized Users

Many shared hosting solutions are set up with cPanel, which typically gives users FTP access to their web server environment by default. FTP is not encrypted like communications over SSH, so configuring sFTP is recommended if that’s all your host allows. 

Read more

Matt Glaman: Using Drupal Console to manage your RESTful endpoints

Planet Drupal - 1. Mai 2018 - 11:00
Using Drupal Console to manage your RESTful endpoints mglaman Tue, 05/01/2018 - 04:00

This is a follow up to my early blog post about enabling RESTful web services in Drupal 8Jesus Olivas, one of the creators of Drupal Console, brought up that you can actually manage your RESTful endpoint plugin configurations direct from the command line!

Studie: Erfahrene Softwareentwickler verdienen im Durchschnitt 63.000 Euro in Deutschland

heise online Newsticker - 1. Mai 2018 - 10:30
Die Jobvermittlungsbörse für Softwareentwickler Honeypot.io, hat auf Basis eigener Daten das Einkommensgefüge von Developern in Deutschland untersucht. Demnach erzielen Full-Stack-Entwickler und DevOps-Spezialisten durchschnittlich die höchsten Gehälter.

Appnovation Technologies: Expert Corner: Getting started with React and Drupal

Planet Drupal - 1. Mai 2018 - 9:00
Expert Corner: Getting started with React and Drupal Over the weekend I decided it was long overdue that I learnt React, or at least understood what all the fuss was about, so with npm in hand I installed yarn and started my quest. We're going to use Create React App to setup our base React install. First install then run the command to create a react app called "drupal-react": ...

Wildlife Photographer of the Year: Siegerbild disqualifiziert

heise online Newsticker - 1. Mai 2018 - 7:00
Mit dem Foto eines Ameisenbären hatte Marcio Cabral beim Wildlife Photographer of the Year Award die Kategorie "Tiere in ihrer Umgebung" gewonnen. Jetzt wurde das Bild wegen Zweifeln an der Echtheit disqualifiziert.

Lullabot: JSON-RPC to decouple everything else

Planet Drupal - 1. Mai 2018 - 6:43

At this point, you may have read several DrupalCon retrospectives. You probably know that the best part of DrupalCon is the community aspect. During his keynote, Steve Francia, made sure to highlight how extraordinary the Drupal community is in this regard.

One of the things I, personally, was looking forward to was getting together with the API-First initiative people. I even printed some pink decoupled t-shirts for our joint presentation on the state of the initiative. Wim brought Belgian chocolates!

undefined

I love that at DrupalCon, if you have a topic of interest around an aspect of Drupal, you will find ample opportunity to talk about it with brilliant people. Even if you are coming in to DrupalCon without company, you will get a chance to meet others in the sprints, the BoFs, the social events, etc.

During this week, the API-First initiative team discussed an important topic that has been missing from the decoupled Drupal ecosystem: RPC requests. After initial conversations in a BoF, we decided to start a Drupal module to implement the JSON-RPC specification.

undefined

Wikipedia defines RPC as follows:

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.

The JSON API module in Drupal is designed to only work with entities because it relies heavily on the Entity Query API and the Entity subsystem. For instance, it would be nearly impossible to keep nested filters that traverse non-entity resources. On the other hand, core’s REST collections based on Views, do not provide pagination, documentation or discoverability. Additionally, in many instances, Views will not have support for what you need to do.

We need RPC in Drupal for decoupled interactions that are not solely predicated on entities. We’re missing a way to execute actions on the Drupal server and expose data that is not based on entities, for read and write. For example, we may want to allow an authenticated remote agent to clear caches on a site. I will admit that some interactions would be better represented in a RESTful paradigm, with CRUD actions in an stateless manner on resources that represent Drupal’s internals. However because of Drupal’s idiosyncrasies sometimes we need to use JSON-RPC. At the end of the day, we need to be pragmatic and allow other developers to resolve their needs in a decoupled project. For instance the JS initiative needs a list of permissions to render the admin UI, and those are stored in code with a special implementation.

Why the current ecosystem was not enough

After the initial debate we came to the realization that you can do everything you need with the current ecosystem, but it is error prone. Furthermore, the developer experience leaves much to be desired.

Custom controllers

One of the recommended solutions has been to just create a route and execute a controller that does whatever you need. This solution has the tendency to lead to a collection of unrelated controllers that are completely undocumented and impossible to discover from the front-end consumer perspective. Additionally, there is no validation of the inputs and outputs for this controller, unless you implement said validation from scratch in every controller.

Custom REST resources

Custom REST resources have also been used to expose this missing non-entity data and execute arbitrary actions in Drupal. Custom REST resources don’t get automatic documentation. They are also not discoverable by consumers. On top of that, collection support is rather limited given that you need to build a custom Views integration if it’s not based on an entity. Moreover, the REST module assumes that you are exposing REST resources. Our RPC endpoints may not fit well into REST resources.

Custom GraphQL queries and mutators

GraphQL solves the problem of documentation and discovery, given it covers schemas as a cornerstone of the implementation. Nevertheless, the complexity to do this both in Drupal and on the client side is non-trivial. Most important, bringing in all the might of GraphQL for this simple task seems excessive. This is a good option if you are already using GraphQL to expose your entities.

The JSON-RPC module

Key contributor Gabe Sullice (Acquia OCTO) and I discussed this problem at length and in the open in the #contenta Slack channel. We decided that the best way to approach this problem was to introduce a dedicated and lightweight tool.

The JSON-RPC module will allow you to create type-safe RPC endpoints that are discoverable and automatically documented. All you need to do is to create a JsonRpcMethod.

Each plugin will need to declare:

  • A method name. This will be the plugin ID. For instance: plugins.list to list all the plugins of a given type.
  • The input parameters that the endpoint takes. This is done via annotations in the plugin definition. You need to declare the schema of your parameters, both for validation and documentation.
  • The schema of the response of the endpoint.
  • The PHP code to execute.
  • The required access necessary to execute this call.

This may seem a little verbose, but the benefits clearly surpass the annoyances. What you will get for free by providing this information is:

  • Your API will follow a widely-used standard. That means that your front-end consumers will be able to use JSON-RPC libraries.
  • Your methods are discoverable by consumers.
  • Your input and outputs are clearly documented, and the documentation is kept up to date.
  • The validation ensures that all the input parameters are valid according to your schema. It also ensures that your code responds with the output your documentation promised.
  • The module takes care of several contrived implementation details. Among those are: error handling, bubbling the cacheability metatada, specification compliance, etc.

As you can see, we designed this module to help Drupal sites implement secure, maintainable, understandable and reliable remote procedure calls. This is essential because custom endpoints are often the most insecure and fragile bits of code in a Drupal installation. This module aims to help mitigate that problem.

Usage

The JSON-RPC module ships with a sub-module called JSON-RPC Core. This sub-module exposes some necessary data for the JS modernization initiative. It also executes other common tasks that Drupal core handles. It is the best place to start learning more about how to implement your plugin.

Let's take a look at the plugins.list endpoint.

/** * Lists the plugin definitions of a given type. * * @JsonRpcMethod( * id = "plugins.list", * usage = @Translation("List defined plugins for a given plugin type."), * access = {"administer site configuration"}, * params = { * "page" = @JsonRpcParameterDefinition(factory = "\Drupal\jsonrpc\ParameterFactory\PaginationParameterFactory"), * "service" = @JsonRpcParameterDefinition(schema={"type"="string"}), * } * ) */ class Plugins extends JsonRpcMethodBase {

In the code you will notice the @JsonRpcMethod annotation. That contains important metadata such as the method's name, a list of permissions and the description. The annotation also contains other annotations for the input parameters. Just like you use @Translation you can use other custom annotations. In this case each parameter is a @JsonRpcParameterDefinition annotation that takes either a schema or a factory key.

If a parameter uses the schema key it means that the input is passed as-is to the method. The JSON schema will ensure validation. If a parameter uses the factory key that class will take control of it. One reason to use a factory over a schema is when you need to prepare a parameter. Passing an entity UUID and upcasting it to the fully-loaded entity would be an example. The other reason to choose a factory is to provide a parameter definition that can be reused in several RPC plugins. An example of this is the pagination parameter for lists of results. The class contains a method that exposes the JSON schema, again, for input validation. Additionally it should have a ::doTransform() method that can process the input into a prepared parameter output.

The rest of the code for the plugin is very simple. There is a method that defines the JSON schema of the output. Note that the other schemas define the shape of the input data, this one refers to the output of the RPC method.

/** * {@inheritdoc} */ public static function outputSchema() { // Learn more about JSON-Schema return [ 'type' => 'object', 'patternProperties' => [ '.{1,}' => [ 'class' => [ 'type' => 'string' ], 'uri' => [ 'type' => 'string' ], 'description' => [ 'type' => 'string' ], 'provider' => [ 'type' => 'string' ], 'id' => [ 'type' => 'string' ], ], ], ]; }

Finally, the ::execute() method does the actual work. In this example it loads the plugins of the type specified in the service parameter.

/** * {@inheritdoc} * * @throws \Drupal\jsonrpc\Exception\JsonRpcException */ public function execute(ParameterBag $params) { // [Code simplified for the sake of the example] $paginator = $params->get('page'); $service = $params->get('service'); $definitions = $this->container->get($service)->getDefinitions(); return array_slice($definitions, $paginator['offset'], $paginator['limit']); } Try it!

The following is a hypothetical RPC method for the sake of the example. It triggers a backup process that uploads the backup to a pre-configured FTP server.

Visit JSON-RPC to learn more about the specification and other available options.

To trigger the backup send a POST request to /jsonrpc in your Drupal installation with the following body:

{ "jsonrpc": "2.0", "method": "backup_migrate.backup", "params": { "subjects": ["database", "files"], "destination": "sftp_server_1" }, "id": "trigger-backup" }

This would return with the following response:

{ "jsonrpc": "2.0", "id": "trigger-backup", "result": { "status": "success", "backedUp": ["database", "files"] "uploadedTo": "/…/backups/my-site-20180524.tar.gz" } }

This module is very experimental at the moment. It’s in alpha stage, and some features are still being ironed out. However, it is ready to try. Please report findings in the issue queue; that's a wonderful way to contribute back to the API-First initiative.

Many thanks to Gabe Sullice, co-author of the module, and passionate debater, for tag teaming on this module. I hope that this module will be instrumental to coming improvements to the user experience both in core's admin UI and actual Drupal sites. This module will soon be part of Contenta CMS.

Header photo by Johnson Wang.

Drupal.org blog: What’s new on Drupal.org? - April 2018

Planet Drupal - 30. April 2018 - 23:18

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

Drupal.org Updates Drupal.org's new front page and persona pages launched

As you've probably seen by now, just before DrupalCon Nashville we launched a makeover of the Drupal.org front page. This was a research-based redesign focused on addressing the three key personas that come to Drupal.org: Developers, Marketers/Content Editors, and Agencies.

The new redesign simplifies the number of calls to action on the front page, and directs each of these personas into a more focused funnel, to ensure they are more likely to find the information they really need. To learn more about this redesign and the Promote Drupal initiative, read our recent blog post. We want to thank SixEleven for their help with this new design initiative.

Promote Drupal Initiative

Redesigning the front page was just the start, we kicked off DrupalCon by announcing a new 'Promote Drupal' initiative, asking the community to come together to help bring Drupal to new audiences, and to convince people who've used older versions in the past to give Drupal 8 another look.

We need your support to make the Promote Drupal initiative happen!

Updated top navigation and IA

Along with the front page changes, we've updated Drupal.org's top level IA, providing a more logical structure for navigating to the major areas of the site depending on a user's persona.

Promoting Nonprofit solutions built with Drupal

And last, but not least, in our efforts to #PromoteDrupal we've launched a new Nonprofit solution page, promoting the power of Drupal for Nonprofits and NGO's around the globe. Drupal has long been the choice for well-recognized, global nonprofit organizations to extend their reach and maximize their impact.

Simplify Drupal Initiatives

In project founder Dries Buytaert's keynote at DrupalCon Nashville he proposed a series of initiatives to simplify Drupal - lowering the barriers to adoption and improving the user experience of site administrators and content editors. Some of these initiatives are to improve features of Drupal core itself, whereas others are focused on the evaluator experience and will be managed in collaboration with the Drupal Association.

In particular, the Drupal Association will collaborate with the core initiatives teams on:

These initiatives are not going to be quick or easy. They rely on collaboration between the Drupal Association, Drupal's core committer team, and a variety of volunteers throughout the community. We'll need your help.

Drupal.org and GDPR

GDPR, the General Data Protection Regulation passed by the EU last year, begins enforcement on May 25th, 2018. We've been preparing for this new regulation for some time, and will be implementing a few changes in the coming weeks:

Security Release SA-CORE-2018-003

Drupal Core coordinated a security release with the CKEditor team to ensure that the security fix for CKEditor was immediately available in Drupal 8. As Drupal becomes further integrated into a world of third party dependencies, this kind of coordination between open source projects becomes increasingly important. We want to thank the CKEditor team and the volunteer Drupal Security team for their hard work and careful collaboration.

SA-CORE-2018-004

After the release of SA-CORE-2018-002 in March, a related vulnerability was discovered and an additional security advisory for Drupal 7 and 8 released in April. If you have not yet updated your Drupal sites to address these vulnerabilities they may already be compromised. If that is the case, we encourage you to read this PSA, which provides some steps you can take.

Security releases tend to spark quite a bit of conversation in the community about the nature of software security, proprietary vs open source, and related issues. Community member @rickmanelius provided some much-needed context to keep these security focused efforts in perspective:

The recent SA-CORE-2018-004 and SA-CORE-2018-002 security advisories have sparked a lot of conversations in the Drupal community regarding all things security. IMHO, it's important to highlight several talking points to keep things in perspective.

— Rick Manelius, PhD (@rickmanelius) April 26, 2018

DrupalCI: Support for DrupalCI.yml

DrupalCI now supports the use of Drupalci.yml files in projects to customize and override elements of testing. This makes the testing capability of DrupalCI much more powerful and flexible for project maintainers. We're still working on documenting these new features, but you can read about the new features here.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Chromatic: Lessons Learned from Localization, Part 2

Planet Drupal - 30. April 2018 - 23:03

We recently helped implement a Japanese translation for a client’s site - which was a pretty sizable challenge! The site was already broken down by country, but all the countries were in English. We ran into some unexpected challenges and wanted to break down how we overcame them.

Jacob Rockowitz: Welcoming people to Drupal's diverse and inclusive community

Planet Drupal - 30. April 2018 - 22:48

The importance of welcoming people to the Drupal community

Our meetups and in-person interactions are where we welcome and include new people in our community. Of course, people come and go from every community; new faces bring new ideas and innovations.

At the beginning of DrupalCon Nashville at the Community Summit, someone told a story of how they attended a meetup and literally no one talked to them or even really acknowledged their presence. As a result, the individual never returned to that meetup. Organizers of meetups absolutely need to make a concerted effort to make sure that everyone who attends is - minimally - welcomed and acknowledged - that is community-building 101. This story really sat with me because it made me question whether I’m doing enough at the local NYC Drupal Meetup to make people feel welcomed and included.

Remembering who welcomed me to the Drupal community

I ran into Robbie Holmes (robbiethegeek) at DrupalCon and standing in exhibition hall, we reminisced about how he was the first person who welcomed me to the Drupal community. An interesting fact about our relationship is that we grew up around the corner from each other in Brooklyn and knew the same people, but met for the first time in the Drupal community. For many years, Robbie, with the help of others in the community, would always offer to split off from the general, sometimes very technical discussion, to offer a newbie discussion where people new to Drupal can ask them anything and get help. To date, Alexander Ross (bleen) was initiating these discussions at the NYC Drupal Meetup, but it is not reasonable to expect one person to be responsible for welcoming people to the Drupal community.

So, I am going to...Read More

Drupal blog: How Drupal influences other Open Source projects

Planet Drupal - 30. April 2018 - 18:48

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

If you are interested in Open Source and have some time this weekend, watch Steve Francia's DrupalCon keynote called "Drupal and the secret of my success". Steve has been involved in Open Source for over 20 years, and has had the unique opportunity to lead three of the most successful Open Source companies in history. He was Chief Developer Advocate of MongoDB, Chief Operator of Docker, and now he is the Product Lead for the Go programming language at Google. Watch the video to hear Steve's personal story about how Drupal influenced his career, in addition to influencing MongoDB, Docker and Go. I don't often get emotional, but I had to wipe a few tears away during his presentation. Thanks for telling your story and being an inspiration, Steve!

EU-Kommission: Auch Europäer im Ausland sollen .eu-Domains nutzen können

heise online Newsticker - 30. April 2018 - 18:00
Die EU-Kommission will die Top Level Domain .eu für europäische Bürger und Firmen öffnen, die ihren Wohn- oder Firmensitz in Drittstaaten außerhalb des Europäischen Wirtschaftsraums haben. Ein neuer Beirat für die Domainverwaltung ist geplant.