Back

Codeburst

25 Node JS Tutorials

2018-03-13 15:04:13

Learn Node JS by exploring these 25 tutorials.

This article highlights 25 Node JS tutorials written by CodeBurst authors. Whether you’re brand new to Node, or an experienced developer, there’s something here for everyone.

Table Of Contents (Clickable)

  1. Series (multi-part tutorials)
  2. Infos
  3. Tutorials
  4. Top Node JS Courses

Series

Building a Budget Manager with Vue.js and Node.js

In this five part tutorial series you’ll learn how to build a complete Vue.js and Node.js Budget Manager application.By Gustavo Domaradzki.

Build a simple Weather App with Node.js in just 16 lines of code

In part one you’ll learn to make API calls and build a Command Line Weather App in just 15 minutes. In part two, we’ll upgrade our program to a full fledge application where users can type in a city name and get real-time weather data instantly displayed on their screen. By Brandon Morelli.

Node.js By Example

This four part series slowly introduces concepts by example as they relate to the goal at hand, building a web application. In the end, we will have an authenticated todo REST API web application persisted by a SQL database. By John Tucker.

Getting Started With Node.js — All You Wanted To Know

This three part series starts with a broad overview of Node.JS, then explains application setup, NPM, and finally the event loop/multi-threading. By Pramod Chandrayan

Build a simple Twitter Bot with Node.js in just 38 lines of code

Tutorials don’t have to be complicated. Together we’ll build a simple Twitter favorite bot with Node.js in just 38 lines of code. In part two, we’ll expand the capabilities of our bot and make it do some cool stuff! By Brandon Morelli.

CPU Intensive Node.js

This two part series explores the issues and solutions around running CPU intensive code in Node.js; in particular in a web server. By John Tucker

Infos

Node.js V8 internals: an illustrative primer

An investigation (sort of) into the JavaScript V8 engine. The complex inner workings of Node explained in a fantastically simple way. By Vardan Grigoryan (vardanator).

Node.js V8 internals: an illustrative primer

Node.js, MySQL and promises

Like most I/O operations in Node.js, database access is asynchronous. It’s a great feature, because other operations can be performed while waiting for the results. But if you come from a different programming language, this can be really annoying. By Michał Męciński.

Node.js, MySQL and promises

4 ways for making HTTP(S) requests with Node.js

During your career as a web developer you will work with HTTP requests all the time. This is why in the following post I want to introduce you to 4 different ways for making HTTP requests in Node.js. By @Valentino Gagliardi.

4 ways for making HTTP(S) requests with Node.js

Tutorials

A Guide to Automating & Scraping the Web with JavaScript (Chrome + Puppeteer + Node JS)

Learn to Automate and Scrape the web with Headless Chrome. By Brandon Morelli.

A Guide to Automating & Scraping the Web with JavaScript (Chrome + Puppeteer + Node JS)

Going real time with Socket.IO, Node.Js, and React

Learn the basics of WebSockets and Socket.IO while pairing your first real-time server with a React frontend. By Valentino Gagliardi.

Going real time with Socket.IO, Node.Js, and React

Using Node.js & Express.js to save data to MongoDB Database

In this tutorial you will learn how to use Express.js, Node.js and MongoDB.js. You will be creating a very simple Node application, that will allow users to input data that they want to store in a MongoDB database. By Jennifer Bland.

Using Node.js & Express.js to save data to MongoDB Database

Node.js REST API Facebook Login

In this tutorial we will integrate Facebook authentication to a REST API created using Express.js. On the backend side we will use MongoDB as a database, Node.js and Express.js. By Ivan Vasiljevic.

Node.js REST API Facebook Login

How to Create and Publish Your First Node.js Module

An oldie but still a goodie — learn what NPM is and how to publish your first module. By Joanne.

How to Create and Publish Your First Node.js Module

Learn to build an Amazon Alexa Skill with Node.js

Learn why voice is the future, and build your first Amazon Alexa Skill in just 20 minutes. (And then get Amazon to pay you for it). By Brandon Morelli

Learn to build an Amazon Alexa Skill with Node.js (and get paid to do it)

Beautiful Node: Building an API endpoint with Express, Mongoose, Validation and Promises

Learn how to create a beautiful API endpoint utilizing Mongoose validation and async/await. By Daniel Khan.

Beautiful Node: Building an API endpoint with Express, Mongoose, Validation and Promises

Build a Rest API for Node & Mysql 2018 JWT

Learn to build a maintainable, restful API for Node.js and Mysql. By Brian Alois

Build a Rest API for Node & Mysql 2018 JWT

Top Node JS Courses

Want to learn Node? Check out these trending courses. Disclosure: I write reviews and receive compensation from the companies I review.

The Complete Node.js Developer Course (2nd Edition)

4.7/5 Stars || 26 Hours of Video || 66,000 Students

Learn Node.js by building real-world applications with Node, Express, MongoDB, Mocha, and more!

The Complete Node.js Developer Course (2nd Edition)

Node with React: Full Stack Web Development

4.7/5 Stars || 25 Hours of Video || 25,000 Students

Build and deploy fullstack web apps with NodeJS, React, Redux, Express, and MongoDB.

Node with React: Fullstack Web Development | Udemy

Learn and Understand NodeJS

4.5/5 Stars || 13 Hours of Video || 75,000 Students

Dive deep under the hood of NodeJS. Learn V8, Express, the MEAN stack, core Javascript concepts, and more.

Learn and Understand NodeJS | Udemy

Closing Notes:

Thanks for Reading! ✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

If this post was helpful, please click the clap 👏 button below a few times to show your support! ⬇⬇


25 Node JS Tutorials was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more

5 Reasons Why I Love React Native

2018-03-13 15:00:10

React Native is very popular these days, and thousands of apps are already built using React Native. Big names like Facebook, AirBnB, Uber, and many other companies have embraced React Native and are building their latest apps using React Native.

I have been writing apps in React Native for our startup for almost two years now, and here are some of the things I love about it.

1. If you know Javascript, it is easy to learn.

I started writing my first React Native app, with zero prior experience in mobile application development. I knew Javascript, and that was all I needed to get started. Even React was a new concept to me. Web developers can leverage their knowledge in Javascript to write React Native apps.

Once you learn the React lifecycle components and the basics of ES6 (React Native uses ES6 standards for Javascript), you are all set to get started with your first React Native application.

Facebook’s official documentation is very helpful and provides a good insight into React Native components and APIs.

You are going to learn on the fly as you code. Isn’t that the best way to learn anyways?

2. Hot Reloading! Don’t ever waste time recompiling.

This is one of my most favorite aspects of developing React Native Apps. Coming from an enterprise Java background this was huge for me.

Imagine retaining the state of your application and watch it reload as you make your changes. If you are working on a feature few screens away from the main screen, it will require you to navigate through multiple clicks, every time you make changes to the code.

With Hot Reloading, you don’t have to waste any time navigating through those screens to make sure your code worked. The application’s state is maintained, and you get to watch it all reload right in front of your eyes in less than few seconds. The idea is to keep the app running and watch any changes made during runtime take effect, without a complete relaunch of the app.

Cmd+D and “Enable Hot Reloading” does the trick on the emulator.

This saves so much of the developer time. Check out this video to see how it works in action.

3. It builds pure Native Apps.

Unlike other frameworks like Cordova that are mostly just a Webview, React Native is used to build truly native apps. Webviews do not provide the natural user experience that comes with React Native.

With React Native the underlying widgets are all native components, hence giving the user a seamless experience. This truly makes a huge difference.

It is really impressive since you are coding in Javascript, and rendering components that are native to the platform. This is one of the reasons that apps built using React Native have a superior user experience in comparison to frameworks that use web-views.

A simple example here shows the user interface for a date picker widget on both Android and iOS. Both the date pickers are native widgets.

Android Date Picker— Underlying Native Widget
iOS Date Picker — Underlying Native Widget

These are some aspects of React Native that makes the developer’s life much easier and we don’t need to reinvent the wheel here. There is absolutely no additional UI coding required to make these native components render cross platforms.

4. Code Once — Works on Android and iOS

The previous example brings me to the next most important reason why I have enjoyed working with React Native — It’s cross-platform capabilities.

You don’t need to know Objective-C, Swift or Java. With Javascript and JSX you build your app which works very well cross-platforms. From my experience, almost 95% of the code is shared between iOS and Android, with minor tweaks to polish the end product on both platforms. Isn’t that just great? You don’t have to have multiple teams and codebases to support the same app cross-platforms.

Instead, you have one team and one codebase that works on both the iOS and Android versions of the app. This is a huge win for small companies and a cost and time saver.

Although I have not tried it yet, React Native works well for Windows too. The more the merrier obviously.

With React Native build Android, iOS and Windows Apps all in Javascript.

5. Huge Community

Over the last couple years, React Native has gained so much popularity, that there are plenty of developers contributing to make React Native better everyday.

The React Native GitHub repo is open source and has thousands of contributors who are very active.

React Native Community

There is a new discussion forum for React Native that you can be a part of as well.

Stack Overflow is another place which has plenty of resources and questions answered on React Native.

The community is huge and growing. Many problems have already been solved, and you are most likely not going to re-invent the wheel during your development experience.

Overall, I think React Native has come to stay and definitely has a brilliant future in developing cross-platform, native apps, which are UI centric. I hope you build your first React Native app, very soon.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

5 Reasons Why I Love React Native was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more

Upgrade to Webpack 4

2018-03-13 14:59:59

Webpack 4 (codename Legato) was released two weeks back. And it is packed with a lot of shiny features. Unlike Webpack 3, which was not a major upgrade over its predecessor, Webpack 4 has a string of compelling features.

Major changes to look out for -

1. Reduced Build Time
The build time has gone down massively (more than 60%)

2. Zero configuration
You can now start using webpack with any project without any config file (introducing mode)

I recently upgraded my React-Redux Boilerplate to Webpack 4. There are no clear docs out there for migration yet, so it took me quite some time and struggle to complete the upgrade. I am writing down everything I figured so it can help anyone who wants to upgrade.

The following are the config changes that need to be done.

  • Mode
  • Plugins
  • Dependencies

Mode

Webpack 4 has two modes — development and production.

Previously we passed the flag -p to the webpack command to run a production build. With Webpack 4, you should always pass in mode option. You have two ways to pass in mode,

1. Pass through npm script

In your package.json -

"build": "webpack --config config/webpack.dev.config.js --mode development",
"build:prod": "webpack --config config/webpack.prod.config.js --mode production"

2. Pass through config file

In your webpack.dev.config.js

mode: 'development'

In your webpack.prod.config.js

mode: 'production'

Plugins

The following plugins have been removed from Webpack 4 which were extensively used in previous versions.

  • NoEmitOnErrorsPlugin
  • ModuleConcatenationPlugin
  • NamedModulesPlugin
  • CommonsChunkPlugin

Now instead, the configuration of these plugins should go inside the key optimization in the config file with their corresponding options.

This snippet might give you more info

plugins: [
  // Not used like this anymore 
  new webpack.NamedModulesPlugin(),
new webpack.NoEmitOnErrorsPlugin(),
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
children: true,
minChunks: 2,
async: true,
}),
new webpack.optimize.ModuleConcatenationPlugin()
],
Instead, the above plugins are used like this
optimization: {

namedModules: true, // NamedModulesPlugin()
  splitChunks: { // CommonsChunkPlugin()
name: 'vendor',
minChunks: 2
},
  noEmitOnErrors: true, // NoEmitOnErrorsPlugin
  concatenateModules: true //ModuleConcatenationPlugin
}

Dependencies

If you’re using dependencies like webpack-hot-middleware and image-webpack-loader, make sure you upgrade them as well. I ran into a weird issue with webpack-hot-middleware but once I upgraded it to the latest version, it got resolved automatically.

You can refer to this commit in React-Redux Boilerplate for reference.

Webpack 4 is great in so many ways. But the lack of docs for upgrade is a bummer. But then, we’re all amazing problem solvers, so we don’t mind.

If you’re planning to upgrade to Webpack 4, don’t think twice, your dev experience will definitely multifold. God Speed!

Have a nice day! ✨

Originally published at dev.to.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

Upgrade to Webpack 4 🎉 was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more

What Is Not A Blockchain ?

2018-03-13 10:35:06

Being a blockchain enthusiast i am so intrigued by this decentralized technology and extremely fascinated by the change it is bringing to this fin-tech and other Identity management related industry. Also the way it is democratizing the digital economy is certainly a game changer. If you all have been lately reading and listening a lot about about this buzz of bitcoin, ethereum and how blockchain has been empowering these digital currency, the challenges, the advantages it has to offer, all must be quite exciting for all of you also.

I have already covered in the past about

  1. Blockchain
  2. Bitcoin
  3. Ethereum
  4. Litecoin
  5. Ripple
  6. Smart Contract
  7. NEO Blockchain
  8. Wallet

Where we have understood a lot about What Is Blockchain ? But today we will try to understand:

What Is Not A Blockchain ?

As it is known that the technology at the heart of bitcoin, ripple, litecoin and other virtual currencies is blockchain, which is an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. But what you don’t know is that

1. Blockchain Is Not A Bitcoin :

Bitcoin is not a Blockchain and Vice-versa. Bitcoin in reality sits at the top of the blockchain like our apps sits on the top of the database. Where apps does all transaction to store & access the data into the database structure, similarly blockchain holds all the bitcoin transactions records which can be verified. Bitcoin is a pure digital currency which uses the blockchain as underlying tech to use it as a database ledger.

Business blockchain manages digital identity with priority and makes and picks up some selective transactions as compared to bitcoins which utilizes intensive Proof of Work, which is quite resource intensive.

2. Blockchain Is Not A Currency:

Again as we discussed earlier blockhchain cannot be a digital currency like bitcoin as it is mainly a database which holds transaction records. It is similar to say that mongoDb the database behind paypal is not a currency.

3. Blockchain Is Not A Product:

Many Decentralized Apps are being built on blockchain where it is acting like fabric but the blockchain itself is not that app or a product. These products use it as a utility and is mainly built on top of it.

4. Blockchain is not a replacement to existing transaction processing mechanism(At least in the current given context)

To be able to replace our currently existing transaction mechanism blockchain has to fulfill some important critieria like :

  1. It has a widely accepted business network where transaction can happen seamlessly and assets are transacted securley
  2. It Should be have & be able to verify multiple accounts across the distributed network.
  3. Should be able to trace & keep a record of who did the transaction and what value has been transacted at which timestamp.
  4. Should be able to do secure and trusted transactions
  5. Should hold one true record which is to be shared across the network to be verified.

If all the above value and criteria is met than only it can a candidate to replace our conventional transaction system else it will be too early to say that it can replace it fully.

5. Blockchain is not a replacement to our existing distributed database mechanism:

Currently many apps are built over this distributed database technology and this tech works wonderful where there is no need of business network, so Blockchain being a decentralized database can complement it well, but can’t replace it fully, because of its limitation to work on large business network.

6. Blockchian Is Not Yet Matured Enough

Yes it has scaled to fast too quickly as compoared to TCP/IP Inernet Wave but it has yet to go through that gestation period where we can say it has fully matured and is widely accepted just like internet wave. For blockchain to revolutionise this digital arena needs to overcome many challenges , technology, governance, society, businesses all has to come together to make it a phenomenon. Yes it may take another 10–15 years if not more to attain to that level where it will be completely sweeping the digital wave. If it takes less than what i am predicting it is going to be really a game changer for all the stakeholders who will be the beneficiary of this blockchain revolution.

Yes Blockchain revolution has started to pickup and is going to impact one & all across the globe. When it will completely replace the traditional networking system, is not quite clear now but it will happens for sure

Now that you know what not the blockchain is, let me explain

What Is Blockchain?

To help you explain in more simplified manner, i have a Infographics for you which has been sourced from Blockchainhub.

Summary :

HBR Article Says:

In addition to providing a good template for blockchain’s adoption, TCP/IP has most likely smoothed the way for it. TCP/IP has become ubiquitous, and blockchain applications are being built on top of the digital data, communication, and computation infrastructure, which lowers the cost of experimentation and will allow new use cases to emerge rapidly.
No matter what the context, there’s a strong possibility that blockchain will affect your business. The very big question is when.

I have a feeling that no businesses can afford, in the coming future to compete in this ever changing market without adopting this blockchain revolution. Yes the early movers advantage will play a major role to decide the winners and the losers. So it is a time that you start now, may not be at larger scale, but with smaller investment within your organization to experiment with data management using blockchain. Also you can involve existing bitcoin payment mechanism in your eCommerce or in a game. You should not risk now on building your own network if that it not what suits your risk appetite but it can be a smart move to use the existing Blockchain As A service(BaaS) or Blockchain enabling platform to develop you own business solution over it.

I Always Say :

There is always less risk to take any risk, but if the decision is not timed well it going to hit you hard for sure.

Thanks For Reading, Keep Loving , Keep Investing…. On what, you can decide !


What Is Not A Blockchain ? was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more

Security for Drupal and related server software

2018-03-13 07:05:39

By ADCI Solutions

Drupal is an open-source content management system with a quite complex architecture. It also has a strong security model. Thanks to the big community of developers there is a lot of informative documentation and useful examples of the proper configuration of Drupal website security and keeping this configuration up-to-date.

It should be kept in mind that Drupal is the only one part of the software which is needed to run a website. To protect the whole system from hacking, we need to take care of an entire set of software. It includes some common server settings, the configuration of a web server, PHP and a database. Also, the proper configuration is required for any additional software on a server.

This article focuses on discussing the mentioned key points. It provides some clues which should help the server and website administrators to audit the security of the entire system. We should understand that it’s impossible to create a system which is absolutely safe but if you stick to some common principles, it will help to support an indicator of the safety of your system at the sufficient level.

Security principles

Let’s start with the common security rules. Most of them are applicable not only to the Drupal development and supporting the security of the relevant for the Drupal website functioning infrastructure but also in many other cases:

  • Use widespread solutions that are developed by a large community of users. It can be well maintained open-source libraries, popular Linux distributions and so forth. Always check the integrity of the downloaded code.
  • Limit usage of any additional software. Install new software if you really need it and there is no ability to use the similar functionality from already installed packages. Uninstall all the software that you don’t need.
  • Avoid writing a custom code. Before you start doing it, think carefully whether you can avoid this. A real situation related to the Drupal development is the search for ready solutions on drupal.org before writing custom modules.
  • Deny an access by default. You should grant an access to objects in your system only when it’s necessary.
  • Add roles with required permissions. Each role must be well documented. In that way, it should be easy to support and extend a whole roles/permissions system.
  • Do not use superuser privileges. On Linux-based operating systems only use the root access when required and do this through sudo. In other words, you shouldn’t be logged in as root.
  • Document everything. First of all, it’s about any customizations of your system. It’s quite easy to forget some important details and they can be lost during the system update.
  • Do periodic security checks of your system. You should carefully analyze all suspicious cases and react to them.
  • Take care of backups. You must always have an ability to revert the system back to any of previous states. Besides, you need to be sure that the system makes the workable backups.
  • Do not open the access to your server from the Internet before the server is properly protected.

These principles can be applied to any system, regardless of a set of software and hardware that it uses. However, there are more specific key points what we will discuss further.

Key security objects

In addition to Drupal to run a website, it’s necessary to configure PHP, a web server, and a database server. You may also want to install some software for extending search functionality, for working with cache and so on.

As you see there is a lot of things that require the proper configuration and regular maintenance. Based on said above, we can distinguish the following objects for which we need to ensure security to some extent:

  • Server (common settings)
  • Web server
  • PHP
  • Database
  • Drupal

Server (common settings)

Security of any service available on the Internet begins with a basic configuration of a server. For the Linux-based servers it can include the following steps:

  • Change the login process to the server
  • Setup a firewall by using iptables

Change the login process to the server

By changing the process of logging in to the server, I mean a certain modification of the default server settings. The main goal is to make this process different from the standard one.

For example, any Linux-based system has a superuser that is called root. An attacker can try to pick up a password for this user. However, if a server administrator turns off root logins, such attempts will be unsuccessful. Instead of the root user, we could create a new one and then grant him the necessary permissions.

Most of the discussed changes are related to ssh settings. They are usually located in the /etc/ssh/sshd_config file. Take a look at this configuration:

Port 2345
Protocol 2
PermitRootLogin no
PasswordAuthentication no
UseDNS no
AllowUsers user

It allows a user with a name user connect via ssh to the server by using 2345-port (not standard). It also disables root logins and a password authentication.

Disabling the password authentication is an important step to improve the security of the whole system. The passwordless authentication is more secure. To log in to the server you need to generate an ssh key-pair on a local machine and then copy a public key to the server.

Setup a firewall by using iptables

The iptables utility is the default firewall for Linux systems. It can be used for managing connections to the ports that you specify. If we want to keep the website on the server, in additional to the ssh port it will be necessary to open http and/or https ports.

By default, there are no rules on a clean operating system. Typing the sudo iptables -L command (Ubuntu) returns the following entries:

Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

This means that the server accepts anything from anyone on any port (policy ACCEPT). Let’s try to open the necessary ports and refuse connections to other ports for an input chain.

sudo iptables -A INPUT -p tcp --dport 2345 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

These commands accept connections to 2345-, 80- and 443-ports. Despite this, we still have no other restrictions for other ports. So, you need to add a rule to an end of the input chain that will refuse all inappropriate packets.

sudo iptables -A INPUT -j DROP

That’s all. It should be borne in mind that the settings above may vary greatly depending on a chosen operating system. The main goal here is only an explanation of the basic principles. Be careful when changing network settings. Sometimes it can make a remote server not available for any connections.

Web server

A few general guidelines for setting up a web server. Applying these rules is very important for the functioning of your website. By using server vulnerabilities attackers can manipulate website files, upload malicious scripts and run these scripts somehow.

Access to the website files

There is the main rule — the website files should be editable by a non-root user and shouldn’t be writable by a web server user. The Drupal files/ directory in some cases can be available for writing by the web server’s user. The detailed information on securing file permissions and ownership can be found in the Useful links block at the end of the article.

Restrict an access to some pages on the web server level

Sometimes it may be useful to restrict an access to several pages of the website on the web server level. For example, in a situation when you have a demo website or a website without a registration functionality. So, you can protect the /user and /admin/* routes. For the Apache web server, it can be done by using the mod_authz_host and mod_rewrite modules. Keep in mind that using a http authentication isn’t a secure approach. Thus, the described method is more applicable in a given case.

Remove the unused web server extensions

All additional software on the server is a potential security risk. So, you should minimize a set of necessary tools. If you don’t need something, just remove it.

The same is applicable for the web server. Apache and Nginx web servers have a lot of additional extensions which can be used for some purposes. Carefully check a list of enabled extensions and remove all not used extensions.

Use HTTPS

Usage of the HTTPS protocol makes the website and an access to the private users’ data more secure. Nowadays it’s an absolutely impossible situation when some online stores don’t use encryption for their payment transactions. Moreover, Google sets HTTPS as a ranking indicator. It means the websites which don’t use the HTTPS protocol but at the same time process, some important information (credit cards details, payment transactions, etc.) get a negative impact on search rankings.

An ideal case is if you apply encryption for all websites that have an interaction with users. An obvious example of such an interaction can be the login and registration forms. Users type their passwords to these forms. Even if these passwords look invisible (like black circles in a field) in all browsers, they are passed through a network in an unencrypted form. So, if attackers have an access to the network, they can easily intercept the data entered. Quite often users have the same passwords for different services. This means that access to other services can also be compromised.

HTTP Authentication

It should be clear in what situations you can use an HTTP authentication. Most often you need it to protect an access to a staging website and disable indexing of this website by search bots. However, the HTTP authentication is inherently insecure. It doesn’t use any encryption algorithm. So, the traffic between your browser and the website isn’t encrypted and an attacker can get the access to the website just by copying the “Authorization” HTTP header and sending it the web server.

Also, it’s strongly recommended to keep the htpasswd file outside of a document root. Set read-only permissions for this file (440).

PHP

PHP like other parts of the server infrastructure can contain vulnerabilities. Here much depends on the settings of PHP itself and on what version of PHP is currently used. Of course, you always need to check all available updates and keep PHP updated. However, in some situations, it can be quite difficult or even impossible.

In general, all the work to optimize the safety of the operation of PHP on a server can be divided into three parts:

  • Periodic update of PHP version
  • Avoiding the use of an insecure code, functions, etc.
  • Optimizing PHP settings

Periodic update of PHP version

It’s an obvious thing but, as I mentioned, in some cases updating can be quite difficult or even impossible. It can happen in a situation when you have a lot of legacy code in your application (it doesn’t work in the new PHP version) and the current business strategy doesn’t allow you to spend time on updating this code because it’s time-consuming operation. In such a case, you can try to apply some recommendations which are described below.

Avoiding the use of an insecure code

Writing a secure code is an important step to the whole application security. You should spend some time on a regular basis for reviewing all the custom code that you have. Besides, no one can give a guarantee that the third-party libraries do not contain any vulnerabilities. As I mentioned, even PHP itself can have problems with security (using insecure functions, buffer overflows, etc.).

To solve these problems there is a good solution called Suhosin which can help you to get rid of many security issues. Suhosin was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. It consists of two parts. The first part is a patch for the PHP core which provides a few low-level protections against buffer overflows or format string vulnerabilities. The second part is a PHP extension that implements some additional protections.

Suhosin is a really powerful tool for protecting your server against a lot of vulnerabilities. Unfortunately, it isn’t available for PHP 7. In fact, the work on Suhosin7 is being carried out, but it isn’t finished yet. The author doesn’t recommend using Suhosin7 on production servers.

Optimizing PHP settings

The two easiest steps that we can take in order to optimize the PHP security configuration are disabling unused modules and minimizing an amount of information that users can get about a current PHP installation.

To see all of the compiled PHP modules, run the following command:

$ php -m

It’s recommended to use only the most necessary modules to increase security. Carefully check the entire list and decide what modules you don’t need.

Protection of PHP from hacking is not only an accurate programming but also hiding information about a system. Take a look at this string in the php.ini file:

expose_php = Off

Make sure that this parameter is turned off. Otherwise, PHP will send the installed version in response to all requests in the X-Powered-By header.

The same thing applies to the PHP errors on a website. They can provide some additional info about your server (a type of the web server and its version, the structure of directories, etc.). So, it’s highly recommended to disable this feature on production servers.

display_errors = Off
log_errors = On
error_log = /var/log/httpd/php_scripts_error.log

The settings above allow you to turn off displaying errors occurring all around the website. Also, they activate logging of errors into the specified file.

Those were preliminary steps that will help you increase the security of using PHP on your server even without any significant modification of the system. Now let’s talk about some specific restrictions that you can add to the PHP configuration (php.ini file):

  1. Disable file uploads
    file_uploads = Off
But if such a function is necessary, it’s better to limit a file size.
file_uploads = On
upload_max_filesize = 1M

2. Control system resources
max_execution_time = 30
max_input_time = 30
memory_limit = 50M

You can specify the maximum execution time for each script, the maximum amount of memory and the maximum data read time.

3. Disable PHP functions which allow scripts to refer to other URLs
allow_url_include = Off
allow_url_fopen = Off

If allow_url_fopen is enabled, PHP can use file functions such as file_get_contents. With it, the script can download files from remote servers.

4. Disable dangerous functions
disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Before disabling, make sure that your website doesn’t require any of them.

5. Restrict an access to the file system
open_basedir = “/var/www”

The open_basedir directive allows you to set a directory in which PHP can access files using functions such as fopen, file_get_contents, etc. If the file is outside of this directory, PHP will refuse to open it.

6. Check the session path
session.save_path = “/tmp”

Make sure that the session path is outside the website root directory. Also, it mustn’t be readable or writable by other system users.

Database

What measures you will take to ensure a database security depends primarily on the infrastructure of your application. For example, a Drupal’s database abstraction layer gives you an ability for choosing between different databases. Out of the box, it can be MySQL, SQLite or PostgreSQL. Also, Drupal supports popular MySQL forks such as MariaDB and Percona. You should understand that each system may have different specifications regarding the security.

Also much depends on the fact where you keep the database. The easiest way (in terms of security) is installing the database on the same server where you have a website. However, this approach can have an impact on the whole system’s performance and for this reason server administrators may decide to move the database on the separate server. This is especially true for high-loaded applications.

The first thing that you should do after finishing with the configuration of the server environment is checking if your infrastructure is robust enough and it can’t be easily broken by a DoS attack. In fact, even at the peak of its workload, the server should have some reserve of resources.

As I mentioned before database security settings can be very specific depending on the chosen database server. Within this article, let’s look at some general measures:

  • Database access
    If the database is installed locally, you can disable the access to it from the network. If your database is on the separate server, it should be possible to set what IP address it will listen to. In case of sharing LAN between the web server and the database server set only a LAN IP address (not accessible via the Internet). It can be done by editing the my.conf file. Below is an example of the configuration when you use the same server for the database and the website.
    bind-address=127.0.0.1
  • Databases, users, and permissions
    Review your databases, users, and permissions in order to find any security bottlenecks. Don’t give users more rights than they actually need.
  • PHPMyAdmin and similar tools
    Make sure that you disable graphical tools for working with the database after using them. If you plan to continue using these tools, try to make an access to them as difficult as possible. For example, you can restrict an access to PHPMyAdmin by .htaccess and allow the access from certain trusted IP addresses. Besides, instead of using server applications you can try some local instruments like MySQL Workbench.

Drupal

Drupal has a quite complex architecture. To ensure the safety of this complex system, it’s better to divide all the related work into small parts. During this operation, you will encounter a set of tasks that need to be done only once (set file permissions, configure the settings.php file, etc.). There will be some tasks that require periodic attention (update Drupal and modules). Perhaps others will require you to work closely with the Drupal community.

Here are the two key moments that you should keep in mind:

  • Ensuring the Drupal security isn’t an easy thing but it’s very important for any website. So, you must definitely work on this.
  • The security requires a constant attention from your side.

Files

Make sure that a web server has no writing permissions on Drupal files. Writing permissions may only be needed for cached files, uploads, sessions and temporary directories. The following command grants a write access to the public files directory (Ubuntu/Debian):

$ chown -R www-data:www-data sites/default/files

If your website allows to upload files, pay attention to how you can secure the process of working with these files. Allow only certain file types to be uploaded. Relatively safe are text files and pictures. However, this does not change the fact that users can upload malicious code like a file with a .jpg or .txt extension. To avoid this problem you can try to install the ClamAV module which scans uploaded files for viruses and other malicious code.

The settings.php file

After the initial install, make sure that the settings.php file has no write permissions. Information about this can be found on the Status report page (admin/reports/status in Drupal 8).

In the settings.php file you can set one important option which prevents your website from thinking it is someone’s else. This type of attacks is called HTTP POST Header attacks. To protect a Drupal 7 website against them add the base URL parameter to your settings:

$base_url = 'http://www.example.com';

The similar thing in Drupal 8 is the trusted hosts array:

$settings['trusted_host_patterns'] = [
'^www\.example\.com$',
];

To generate an extra random data Drupal uses salt. Salt is also specified in the settings.php file. For enhanced security, you may put this value to some file which is located outside of the website root. In Drupal 7:

$drupal_hash_salt = file_get_contents('/home/example/salt.txt');

And in Drupal 8:

$settings['hash_salt'] = file_get_contents('/home/example/salt.txt');

Error logs

Drupal provides a mechanism for monitoring a status of your website. Here I mean Recent log messages and Status report pages. Try to check these pages regularly and fix issues found. The Status report page is very useful, especially after a website installation. For example, it can inform you if you forgot to add the trusted hosts settings or there is a write access to the settings.php file. Some types of suspicious activities can be traced simply by looking at the Recent log messages page. As an example imagine a situation when you notice a surge in a registration of new users.

Don’t forget to disable the display of PHP errors. They should not be visible to ordinary users. Although you may see these errors on the Recent log messages page keep in mind that it doesn’t catch all PHP errors. So, check your server log files sometimes.

Changes in Drupal core and contributed modules

This part is about the possible hacks of the Drupal core and contributed modules. Actually, it’s a well-known fact that new developers may cut corners and put their code or some changes directly into Drupal core or the installed contributed modules. This can potentially lead to unpredictable behavior of Drupal itself, as well as to the appearance of vulnerabilities.

To veer away from these problems I recommend to use the Hacked! module. This module scans the currently installed Drupal, contributed modules and themes and compares everything with appropriate versions from drupal.org. If you have the Diff module installed, Hacked! will inform what exact lines were changed. All this makes the Hacked! module a valuable analytical tool for any website.

Users and permissions

Drupal has an intuitive and customizable permissions model. A permission is the simplest element of such system. A set of permissions can be grouped by a role. Then this role may be assigned to the particular users. New permissions and roles may appear during an update of Drupal core and contributed modules. You should periodically check (for example, after updating) which roles are assigned to each user on your website and what permissions are included in these roles. Try to minimize sets of permissions that are included in each role. Don’t give users more permissions than they really need.

A good security practice is a use of a non-standard username (e.g. not adminor root) for user/1 because an attacker will check standard variants in a first place. For greater security, it’s even possible to completely disable the user/1 account.

Another good thing is checking activities of users on your website and lock inactive accounts. The User Expire module provides an ability to define a date on which a specific user account will be locked. Also, it can lock accounts that are inactive for a certain period of time.

Useful modules

Depending on your needs you may find a lot of useful security modules on drupal.org. Here is just a brief list some of them:

Conclusion

In this article, we reviewed a number of practices aimed at securing your website. The review also covers all parts of the necessary infrastructure — from the common server settings to the specific use cases of some Drupal modules.

Many people neglect to monitor the security of their sites and server infrastructure until there are obvious problems. Although even observance of a number of simple rules would help to avoid their appearance. So be patient and always keep an eye on the security of your system. Good luck!

Originally posted at the ADCI Solutions website.

Follow us on social networks: Twitter | FacebookLinkedIn

The Bibliography & Citation module


Security for Drupal and related server software was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more