Амвросия. Амвросия Смотреть что такое "амвросия" в других словарях

Updated on: 2009-11-10

Posted on: 2009-04-28

PHP 5.3 release candidate 1 was released a few days ago. The final version is expected to be released in the upcoming weeks.

This article presents an interview with core PHP developer Lukas Kahwe Smith that has pushed many of the new features of PHP 5.3 as release manager.

Lukas talks about PHP 5.3 new features such as lambda functions, closures and PHAR support. He also explains what are traits, which for now it is a feature that was left out of PHP 5.3.

He also talks about future PHP 5.x and PHP 6, as well how anybody can help in the development of PHP to make it come out faster.

Contents

* Who is Lukas Kahwe Smith?
* Wiki at php.net
* PHP 5.3 features overview


* Future PHP 5.x versions
* What are traits?
* PHP 5.x versus PHP 6
* PHP 6 release
* PHP 6 adoption
* Helping in PHP development
* Conclusion

LKS = Lukas Kahwe Smith
PC = PHPClasses (Manuel Lemos)

PC: Lukas, can you please tell a bit about yourself, where do you come from, where do you work, and what has been you participation in the PHP group?

LKS: My name is Lukas Kahwe Smith. I have an east German mother, an Iranian father and an American stepfather. So there is a bit of almost everything in me. To complete things my step sister is Jewish. Well far east is still missing.

I started a company with a few friends from high school using PHP and MySQL. I think in 2002 or 2003 we went to Frankfurt for the international PHP conference. This was really my step into becoming part of the open source community and not "just" a user.

We actually met you (Manuel Lemos) there and based on your recommendation, the PEAR community suggested that I work on a merge of PEAR::DB and Metabase. After that I became quite involved in PEAR.

Slowly I shifted my interest towards PHP internals as due to work standards I was using less and less PEAR stuff. I started maintaining a wiki of all the open to do tasks, which has now spawned the creation of the official wiki site.

In the summer of 2008 I was then asked to join Johannes as release manager to help out with the organizational aspects.

I sometimes pride myself in being the only non-C coder that has php-src karma. :)

By the way, the PHP Group is actually a small number of people that are sort of the legal entity behind PHP. As such I am not a member of that group. I usually refer to the people working on PHP as the php.net crowd.

* Wiki at php.net

PC: Nice. Can you talk a bit more about that wiki in php.net? What is its purpose? Who should participate in it? How can an interested member of the PHP community get the necessary permissions to participate?

LKS: The purpose if the wiki is to improve the collaboration. So for example we use it for the to do lists for the various active branches. We also use it as a "scratchpad" to note things that need to be added to the manual.

The various teams inside PHP.net are also using it to note processes. Like there are pages that explain how to build PHP on windows.

The biggest thing that came out of the wiki is that people started writing RFCs when they were pitching bigger (and even some smaller) changes.

This makes it much easier for people (core developer and end users alike) to follow what is going on without getting those fairly useless "check the archives" replies. Now they can be pointed to the RFCs to see why something was done the way it was done, or why something was rejected.

One of the big concerns with the wiki is that people would use it as a replacement for adding things into the actual end manual and its something we have to constantly look out for.

The other concern was that content would quickly become unmanageable. As a result we only have people with a CVS account to any PHP.net project write access.

Everybody else can read everything and, of course, request an account. We will then ask the purpose and give access rights. So far all changes people wanted to see happen were either done by granting them access or someone else taking care of this. We are quite liberal here.

* PHP 5.3 features overview

PC: PHP 5.3 is about to be released. Can you give a quick overview of the most important features introduced by this release?

LKS: The biggest and most controversial one is obviously name spaces. We are aware that several people object to our choice of the separator but unfortunately we were unable to find a better alternative.

Other than that a lot of under the hood changes will give people a considerable speed boost, especially if they are not using a byte code cache.

Furthermore we added lambda functions and closures, as well as added some constructs to make working with static methods more powerful.

We also added several extensions of which I especially see PHAR being of huge importance, as it might define the way we package applications in the future.

* Performance versus memory usage

PC: Regarding performance, historically it seems that many performance improvements were made at the expense of greater run time memory usage. Do you agree? Can we expect noticeable increase in memory usage of PHP scripts as consequence of optimizations done on PHP 5.3?

LKS: I am not really an expert, since I do not know the PHP internals. There are some optimizations in PHP that should reduce memory overhead. Constants are now marked as constant internally. I guess in the past they were handled like normal variables, with simply no way in user-land to modify them. I am not sure how much of a difference this will make.

For people running into issue with memory consumption there is now a tool to get a better handle on this. PHP has trouble automatically freeing the memory when you do cyclic references:

$a = new Foo();
$b = new Bar();
$a->bar = $b;
$b->foo = $a;

In large complex scripts constructs like this happen more often that one would expect. Thanks to GSOC 2007 we now have a tool to collect memory when $a and $b are unset.

This does add some memory overhead to track all of the necessary information. However the benefit is that you can either automatically have PHP trigger or manually trigger a process that looks for cyclic references that can be freed up. With a bit of CPU work, this can mark a world of difference for large or long running scripts.

* Lambda functions, closures and PHAR

PC: Can you give a little more detail about what are lambda functions, closures and PHAR and what that is good for, to clarify those that never heard of those features before?

LKS: Lambda functions and closures really are great when working with one of the many internal functions that use callback functions.

Now, instead of polluting your name space with functions you will only call once and thereby risking a fatal error when you have overlapping function names, you can now create an anonymous one shot function on the fly.

PHAR is the result of a "proof of concept" PEAR package called "PHP_Archive".

It allows you to run an archive of several files just like you would be able to run a classic PHP application. So essentially you can take your application, tar it up and have your customers drop this in without having to extract the archive contents.

PHP can read this archive very efficiently. Even byte code caches can handle PHARs. The performance is really good, in some cases due to reduced disk I/O it can even be faster, but I have not checked the latest benchmarks in a while. I think its clear that this reduces a lot of the code maintenance nightmares.

* Future PHP 5.x versions

PC: What features do you expect or wish to be available future PHP 5.x versions?

LKS: Well, I am really unhappy that we did not manage to include traits into PHP 5.3. But something we had to give up, as we were struggling with getting 5.3 out the door because we already had so many features that needed attention. That being said, I do not expect a PHP 5.4.

* What are traits?

PC: Can you elaborate on what are traits and what they are good for in a typical PHP project?

LKS: We do not have multiple inheritance in PHP. The closest we offer right now is being able to implement multiple interfaces. We felt that there is too much of a WTF? factor when two classes have conflicting method definitions.

Traits try to solve the issue differently. Essentially traits are like copy and paste, with a simple syntax to handle any arising conflicts explicitly, which hopefully gets rid of the WTF? factor.

So with a trait you can define and implement your methods in one place and then have those implementations be essentially "copied over" by PHP.

Sounds complex? Its actually quite a lot easier than I think I am making it sound here. Stefan Marr has written an updated RFC that explains everything (including the research behind this).

A possible use case is the classic "Active Record" problem. Forcing all your model classes to inherit from a common base class is really an ugly clutch, but currently there isn"t really a very efficient alternative.

With traits you would not have to do this, as you would simply use a trait for the storage related methods and import them into any model class.

* PHP 5.x versus PHP 6

PC: Andrei Zmievski is basically the architect of the main PHP 6 feature, which is the native Unicode support for representing text strings.

He was in Brazil last October in a great PHP event named CONAPHP - Congresso Nacional de PHP:

Andrei gave a talk named "PHP for Grownups - How 5.3, 6, and intl will change your life" on which he mentioned that PHP 6 is basically PHP 5.3 plus Unicode support.

Do you expect that any other improvements to PHP that will be pushed to PHP 6 rather than future PHP 5.x versions?

LKS: Right. This will remain true for the most part. Andrei is now back on making PHP 6.0 happen, since his new employer is able to give him the required time.

As such we have not made a final decision, but from the vibes I have been getting from most people I talked to on this topic, we might see a PHP 5.4 eventually if we find that the step from 5.3 to 6.0 will be a hindrance to the adoption of 6.0. Or in other words PHP 5.4 might come out after 6.0 is out to backport some features (for example traits). But first we need to figure out PHP 6.0.

* PHP 6 release

PC: Andrei mentioned that PHP 6 is expected to be released some time later in 2009. Do you have a more specific expectation for a release date?

LKS: Based on the experience with PHP 5.3, I would say it will be hard, but not impossible, to even make it in 2010.

* PHP 6 adoption

PC: I think PHP 5 suffered a long delay in adoption mostly due to backwards incompatible changes that would require existing code to be rewritten.

Often companies did not want to spend more money on rewriting code that just works in PHP 4. Do you agree? Do you think PHP 6 may also suffer of that problem? If so, do you expect it to be worse problem under PHP 6?

LKS: Not really. Of course backwards compatibility issues played a factor. PHP 4 was simply quite good. PHP 5 brought with its new features that needed a lot of education for the vast numbers of self taught PHP developers.

Most PHP developers do not have a computer science background, so they did not really understand the new potential of all the new OO features. So it took some time for people to start implementing frameworks and tools to make those new OO features usable for the great masses of developers.

As such PHP 6 will be in a different situation. It will for the most part "only" add Unicode support. While I am sure that many novice programmers struggle with encodings, it will be quickly evident for all users that do have to deal with non ASCII encodings, that its easier to use PHP 6.

The main challenge will be making sure that the performance will not suffer too much because of the obvious additional work that needs to be done behind the scenes to have an engine that is actually encoding aware.

* Helping in PHP development

PC: What can interested developers do to help to make PHP developments come out faster?

LKS: Write tests, write documentation, test our preview releases. For the first part I would suggest to join the test fest efforts, which is a global event that tries to encourage end users to participate in the efforts to write tests.

As for writing documentation we have also worked hard to reduce the barrier to entry. For one the process is now better documented and the tool chain is now entirely comprised of PHP .

For running tests, we just ask people to follow the news on the PHP php.net Web site.

PC: How can anybody contact you to get more information about PHP developments and how they can help?

LKS: What I suggest to subscribe to one of the many mailing lists and simply lurk a bit. Sooner rather than later an opportunity to jump in an help will come.

Also remember that talk is cheap, so I recommend to just try and do something. People who do things will find that there are plenty of people willing to steer them in the right direction. People that just talk have a tendency to just use up time in endless discussion.

Another approach is to hook up with one of the many physical or virtual user communities. Going to a conference to network, or better yet an unconference, which at a much lower price tend to encourage active participation and networking even more.

I can honestly say that joining PHP.net has made me a better programmer and has been my single most effective career building step. My employer also benefits from the huge network of people I know.

* Conclusion

PC: Lukas, thank you for this interview.

LKS: I appreciate your efforts to make PHP code more accessible and to enable people to share their code.

PC: As a side comment, I would like to mention that the PHPClasses blog system, which is custom tailored like everything else on the PHPClasses site, was recently enhanced to allow submission of articles written by any user of the site.

If you or anybody else would like to submit articles of general interest of the PHP community, feel free to do so by going to this page. The site has a reasonably large audience, so posting interesting PHP articles in the blog will give you great instant exposure to any issue that you feel is of the interest of the PHP developers.

LKS: OK, good to know. I might make use of this at times.

PC: Feel free to do it. Thank you.

Seeing technologies you love move forward is an exciting feeling. Another version brings hope of better integrated tools, increased security, and faster ways to complete core tasks, thus making your web application quicker. PHP6’s improvements and and updates are sure to make PHP6 the best version yet.

register_globals, safe_mode, and quote options Removed

register_globals, being the most significant removal, presents a giant security risk as it allows users to modify the querysting to add, change, and remove variable values. It’s highly recommended that you turn this value off on your present PHP build. Magic quotes functions, most notablemagic_quotes_gpc() and magic_quotes(), affect GET, POST, and COOKIE variables. I recommend turning this setting off as well.

Integrated Alternative PHP Cache (APC)

Though this setting will default to off, APC’s caching can significantly increase the speed of your web application. There are currently some great PHP caching libraries available but integrated support can make the system run faster. You can find more information on APC athttp://pecl.php.net/package/APC .

E_STRICT Messages Merged with E_ALL

This move will encourage better programming practices. Of course, you will need to set yourerror_reporting()< level to E_ALL. My websites use E_ALL while on my development server but I change to level 0 (show no errors) when moving then to their hosting server (so that if there is an error, the user can’t see the error).

String Indexes: {} Removed, Becomes Standard Use

As of PHP6, you will no longer be able to use {} to reference the value of a String’s character at a specified position — the standard array position syntax, , will become the only usage.

ASP Style Tags Removed (<% %>)

I have no idea why these were ever implemented. I’ve never used them, nor will I ever.

Increased Unicode Support

PHP does not presently provide adequate Unicode support and PHP6 aims to fix that. Unicode is treated on a per-request basis and cannot be used globally throughout PHP’s functionality — Unicode in PHP becomes inconsistent in usage and takes up more resources.

Other PHP6 Changes:

• ‘var’ will become an alias of ‘public’ without an E_STRICT warning.
• GD1 and FreeType1 versions will be removed.
• Fast CGI will always be on.
• HTTP_*_VARS variable will be removed.
• XMLReader and XMLWriter will be integrated.
• 64-bit integers will be added.
• Ternary ‘?’ valuable will not be required ($myvar = $_POST[‘myvar’] ?: ‘myvalue’;)
• foreach multidimensional arrays work (foreach($a as $k=>list($b,$c));)
• Type-hinted return values (syntax not yet solidified)
• Hardened PHP patch will be added for increased security.

We’ll continue to eagerly monitor PHP6’s progress!

5.6 and PHP 7.0. Why update? Why is there so much old PHP out there? How to establish an up-to-date mindset.

This is a long read, including backgrounds, philosophical questions and trivia on the topic. Do not expect code examples.

Why upgrade to PHP 7.2 anyway?

It’s about time. “PHP 5.6” is the last 5 version around and there will be no security patches from December 2018 on. Any new vulnerabilities will not get fixed any more. The same applies to the initial PHP 7 release, version 7.0. It was released in December 2015. The current version is PHP 7.2 and PHP 7.3 is approaching next.

As of September 2018: PHP 5 is still the most used version of PHP. According on who you are asking, you will get different answers:

• ~80% old PHP according to W3Techs (PHP 7 also includes the deprecated PHP 7.0)
• ~66% old PHP according to WordPress
• ~21% old PHP according to Composer

Why the differences? Well, I believe W3Tech is just crawling the web sniffing the X-Powered-By header to get the version in use today. That includes all the public IPs with all the neglected websites out there. As this gives potential hackers information about the PHP version, it"s common practice to suppress or fake this header, so maybe take this number with an extra grain of salt. WordPress is luckily a little ahead, as it is an active community of "web designers", with a big stake in the United States. And of course, Jordi with Composer is ahead, as those PHPeople are mostly "web developers" who care more about such things.

Who is to blame for all the old PHP?

We and other develoPHPers are thrilled by the new PHProfessionality: Composer, Laravel - for us PHP really made the switch to a modern g language. Still PHP has a bad rep for being the Pretty Home Pages language - and that is also still true. PHP was and still is (beside JavaScript) the first web native language to pick to create home pages. And many of those websites are still around. It’s all those tiny businesses and their semi professional web designers . When you receive $200 to build a website for a restaurant, you are not likely to maintain it for the next 10 years.

And it’s the mass of shady shared hosting providers who are keeping the clients locked-in in long term contracts and outdated versions. I can imagine that half of those PHP 5.6 websites could actually be switched off by now. But that’s not the interest of the hosting providers, they are more interested in keeping them around.

What to do about all the old PHP?

What ever the real number of old PHP installations in the whole internet will be, there soon will be tens of thousands of outdated and unprotected PHP servers out there waiting for hackers to take them over. Maybe we should all gather together and raise awareness for the situation so that more PHPeople wake up and update? What about a hashtag like #uPHPgraded ?

Or maybe, even better, that’s a call to establish new business models? Imagine, what would you do with that army of zombie servers? Bitcoin mining or Facebook farming?

Establish an up-to-date mindset

Keeping your own code and the underlying software dependencies up-to-date is more than just a good practice, it’s a requirement. On fortrabbit, we are in this together. We are responsible keeping the infra up-to-date; your are responsible for the code you write and use. Updating keeps your code secure, fast and agile. Our clients are obligated to use up-to-date software by our terms under 4.13 .

The up-to-date mindset requires some thinking ahead and discipline. Technical debt is the keyword here. Consider upfront that all the code your are having out there, will constantly need some attention and time.

It’s easier when you are code maintainer and business owner, like with a start-up or as a freelancer on your own projects. It’s more complicated in bigger structures and in client-agency relationships. Make maintenance an topic early on, include it in your estimates. Raise awareness on the importance to keep your software up-to-date. Reserve a time budget for that upfront.

Wrapping up

I am very happy to see the PHP language under heavy development coming closer to shorter release cycles and even breaking some old habits. It’s alive. Let’s embrace change and move forward.

PHP is used by 82.4% of all the websites whose server-side programming language we know.

– W3Techs.com

At the end of 2016, PHP 7.1 has come up with latest improvised features like,

• Nullable types
• Iterable pseudo-type
• Void return type
• Class constant visibility modifiers
• Catching multiple exceptions types
• Square bracket syntax for list() and the ability to specify keys in list()

Improvement in speed and maturity of PHP libraries are the areas where PHP has improved a lot.

“Version 7 and 7.1 of PHP are not the revolutionary changes that we got in the later 5.x versions. They are however a proof that PHP has stabilized, matured, and does have a predictable path forward.”

Cal Evans, Technical Manager at Zend Technologies and
godfather of the PHP community

(Source: Cloudways)

Entire PHP community is very much happy with the new updated version as all the drawbacks has been removed that were present in the previous version(s) and this helps to establish a new era for enterprise level projects.

Most of the principal companies were not interested with PHP because of its speed.But in 2016; it has spread to millions with its improved featurettes.

I want to develop web applications using PHP. Am I going the right way? Is this the right platform!

Let me tell you some important features, why you will chose PHP for web development and what are the upcoming trends of PHP in 2017.

1. Equipped with the latest features(stated above)
2. Open Source, Free, and User-friendly. So, you don’t pay a dime.
3. Compatible to all the OS and Servers
4. Includes multiple PHP frameworks
   • MVC coding pattern
   • Object Oriented Programming
5. Security and Cross Platform.

Probable PHP Trends In 2017

Let’s have a look at the probable PHP trends in 2017,

1. With the improvement in several important factors like speed and other, PHP 7 may dominate in all aspects of PHP development .
2. The update and release of major frameworks versions like Symfony, Laravel and Yii which are running with the older version of PHP. These frameworks may completely clinch with PHP 7 important features.
3. Web hosting service providers may upgrade to PHP 7 with the increase popularity and features.

PHP 7 is the way to go

It increases websites security level adding up speed that gives better user experience.

Share your thoughts with comments below about PHP 7. Features and updates that we might have missed, we will surely put it up in our next article.

Related Posts:

OrangeScrum – Project Management Tool Journey, with the Evolution of PHP

Большинство уязвимостей связано с неправильной обработкой данных, получаемых извне, или недостаточно строгой их проверкой. Одной из таких уязвимостей является межсайтовое выполнение сценариев (Сross Site Sсriрting, XSS), которая может привести к дефейсу сайта, перенаправлению пользователя на зараженный ресурс, вставке в веб-ресурс вредоносного кода, краже COOKIE-файлов, сессии и прочей информации. Противостоять XSS своими сила поможет применение лучших практик и рекомендаций по безопасному программированию, о которых и пойдет речь ниже.

$name = strip_tags($_POST["name"]); $name = htmlentities($_POST["name"], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST["name"], ENT_QUOTES);
Встроенные функции PHP, в отличие от самописных, работают гораздо быстрее, а также имеют меньше ошибок безопасности и уязвимостей, т.к. постоянно совершенствуются. Также рекомендуется использовать специальные библиотеки, построенные на основе встроенных функций и фильтров. В качестве примера можно привести OWASP Enterprise Security API (ESAPI), HTML Purifier, Reform, ModSecurity.
Для того чтобы библиотека работала правильно, её нужно предварительно настроить!

2. Используйте подход «белые списки». Подход работает по принципу «что не разрешено, то запрещено». Это стандартный механизм валидации полей для проверки всех входных данных, включая заголовки, куки, строки запросов, скрытые поля, а также длина полей форм, их тип, синтаксис, допустимые символы и другие правила, прежде чем принять данные, которые будут сохраненные и отображены на сайте. Например, если в поле нужно указать фамилию, необходимо разрешить только буквы, дефис и пробелы. Если отклонить все остальное, то фамилия д’Арк будет отклонена - лучше отклонить достоверную информацию, чем принять вредоносные данные.
К сожалению, со своей задачей встроенные фильтры валидации данных PHP не справляются, поэтому рекомендуется писать собственные фильтры и «допиливать» их по мере необходимости. Таким образом, со временем ваши входные методы фильтрации будут усовершенствованы. Стоит также не забывать, что существует слишком много типов активного содержимого и способов кодирования для обхода подобных фильтров. По этой же причине не используйте проверку по «черному списку».

3. Указывайте кодировку на каждой веб-странице. Для каждой веб-страницы необходимо указывать кодировку (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
Пример использования:

или в файле.htaccess веб-сервера Apache дописать строчку:

AddDefaultCharset UTF-8

Если в http-заголовке или в метатегах кодировка не указана, браузер пытается сам определить кодировку страницы. Стандарт HTML 5 не рекомендует использовать такие кодировки, которые включают JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), а также кодировки, основанные на ISO-2022 и EBCDIC. Кроме того, веб-разработчики не должны использовать CESU-8, UTF-7, BOCU-1 и кодировки SCSU. Эти кодировки никогда не предназначались для веб-контента. В случае если тег расположен до тега и заполняется пользовательскими данными, злоумышленник может вставить вредоносный html-код в кодировке UTF-7, обойдя, таким образом, фильтрацию таких символов, как ‘<’ и ‘"’.

4. Установить флаг HttpOnly. Этот Флаг делает клиентские куки недоступными через языки сценариев, такие как JavaScript.
Данная настройка активируется
- в php.ini :

Session.cookie_httponly = True

В скрипте через функцию session_set_cookie_params() :

Void session_set_cookie_params (int $lifetime [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]])
- в веб-приложении через функцию setcookie() :

Bool setcookie (string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]]]])
Эта функция поддерживается последними версиями распространенных браузеров. Однако старые версии некоторых браузеров через XMLHttpRequest и другие мощные браузерные технологии обеспечивают доступ для чтения HTTP-заголовков, в том числе и заголовка Set-Cookie, в котором установлен флаг HttpOnly.

5. Использовать Content Security Policy (CSP). Это заголовок, который позволяет в явном виде объявить «белый список» источников, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр. Даже если злоумышленнику удастся внедрить скрипт в веб-страницу, он не выполниться, если не будет соответствовать разрешенному списку источников.
Для того чтобы воспользоваться CSP, веб-приложение должно через HTTP-заголовок «Content-Security-Policy» посылать политику браузеру.
Пример использования:

Content-Security-Policy: default-src "self"; script-src trustedscripts.example.com style-src "self" ajax.googleapis.com; connect-src "self" https://api.myapp.com realtime.myapp.com:8080; media-src "self" youtube.com; object-src media1.example.com media2.example.com *.cdn.example.com; frame-src "self" youtube.com embed.ly
"Content-Security-Policy" - это официальный http-заголовок, утвержденный W3C, который поддерживается браузерами Chrome 26+, Firefox 24+ и Safari 7+. HTTP-заголовок «X-Content-Security-Policy» используется для Firefox 4-23 и для IE 10-11, заголовок «X-Webkit-CSP» – для Chrome 14-25, Safari 5.1-7.

С позиции веб-разработчика правильно и грамотно развернуть CSP на своем ресурсе довольно проблематично, так как отдельную политику необходимо устанавливать для каждой страницы сайта.

6. Регулярно проводите анализ безопасности кода и тестирование на проникновение. Используйте как ручной, так и автоматизированный подходы. Такие инструменты как Nessus, Nikto и OWASP Zed Attack Proxy помогут обнаружить уязвимости XSS в вашем веб-приложении.

7. Пользователям рекомендуется регулярно обновлять браузер до новой версии и использовать для них расширения, например, NoScript.
Как вы могли заметить, у каждой рекомендации есть свои достоинства и недостатки, поэтому эффективность противодействия межсайтовому выполнению сценария достигается путем применения комплексной защиты, т.е. использования описанных рекомендаций в совокупности.