Plugin installation rules CryptoPro CSP V Mozilla Firefox differ depending on the browser version - 52 and higher, or older.

Mozilla Firefox version below 52

To sign documents in Mozilla Firefox:

• Disable automatic update. To do this, go to "Menu" ⇒ "Settings" ⇒ "Additional" ⇒ "Updates" (Fig. 1).

• Install version 51.0.1 from Mozilla Firefox official website.

For installation CryptoPro Browser plug-in you need to follow the steps:

1. Download the installer from the official website of the Crypto-Pro company www.cryptopro.ru/products/cades/plugin and run the executable file.

2. In the CryptoPro Browser plug-in installation window, click the "Yes" button (Fig. 2-a).

3. Wait for the installation to complete (Fig. 2-b).

4. Click the "OK" button and restart the Internet browser (Fig. 2-c).

Important

After installing CryptoProBrowser plug- inyou need to check if the add-on for working with an electronic signature is installed in the browser CryptoPro EDS Browser plug-in for browsers.

5. Open the browser, press the "Browser menu" button, select the "Add-ons" section (Fig. 3).

6. Open the "Plugins" tab. Opposite the plugin "CryptoPro CAdES NPAPI Browser Plug-in" in the drop-down menu, select the option "Always enable" (Fig. 4).

7. Restart your browser.

Mozilla Firefox version 52 and above

To install CryptoPro Browser plug-in follow the steps:

1. Follow the link www.cryptopro.ru/products/cades/plugin , then select "browser extension" (Fig. 5).

Rice. 5. CryptoPro website

2. Click "Allow" (Fig. 6).

Rice. 6. Request resolution

3. Click "Add" (Fig. 7).

) in the section "Products" -> "CryptoPro EDS Browser plug-in"

When you run the downloaded file, the system will prompt you to elevate the rights to the system administrator. Installation without administrator rights is not possible.

After installation, be sure to restart your browser! Sometimes (in the case of using Chrome) a system restart is required, because. closure of all windows chrome not in all cases unloads the browser from RAM.

Additional settings for FireFox version 52.0 and later

Don't forget to install the plugin

For the plug-in to work in FireFox starting from version 52, you need to install the latest version of the plug-in (at least 2.0.12888) (see ) and a special extension for FireFox.

To install the extension, go from your FireFox to the link . After the transition, you will be prompted to install the extension for FireFox - you must confirm the installation by clicking Install (Install).

Additional settings for FireFox versions prior to 52.0, FireFox ESR (Error: Plugin loaded but no objects created)

After the add-on is installed, its launch is allowed only after confirmation by the user. You can allow the add-on to run either only for the current site or permanently for all sites

Option 1: setting permission to use the add-on only for the current site (https://www.site)

When the error occurred: Plugin is loaded but objects are not created pay attention to the address bar - the add-on icon has appeared in it:

Click on this icon - you will be prompted to run the add-on and remember the permission to run the add-on for this site forever.

Option 2: setting permission to use the add-on for all sites

Open the page with installed Firefox add-ons

Find the CryptoPro CAdES NPAPI Browser Plug-in in the add-on list and change its startup mode to "Always On"

Additional settings for Opera

Open the page with the search for an add-on to install:

Enter "CryptoPro" in the search bar - the extension "CryptoPro Extension for CAdES Browser Plug-in" will be found. Click "Add to Opera" to install.

Additional settings for Yandex browser

For Yandex browser, you need to follow the procedure similar to the case with Opera.

Additional settings for Google Chrome: permission installed add-on

If the add-on is successfully installed, the next time Chrome startup a message will be displayed asking you to confirm the launch of the add-in

In this dialog, you must enable the use of the extension

Posted on 02/03/2016 in

General information

The plugin API involves calling asynchronous operations implemented on the basis of promise objects. You can read more about the specification used in the implementation of the plugin. Promises require two types of handlers:

• onFulfilled- triggered when the promise is in the "successful" state;
• onRejected are fired when the promise is in the "failed" state.

Plugin initialization

To work with the plugin, you need to call the initialization function of the PKCS#11 component plugin.initPKCS11 . This function takes a list of module names as parameters (in the form of an array). You can see the list of provided modules. If modules are not specified, the plugin will initiate all modules.
If it is necessary to specify which cryptographic providers should be used when the capi module is running, the following notation format should be used:

Capi:(prov1),(mode):(prov2),(mode)

In this entry:

• prov1, prov2 - the name of the crypto provider. The following values ​​are currently supported:
• Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider;
• Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider;
• Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider;
• Signal-COM CPGOST Cryptographic Provider;
• Signal-COM GOST R 34.10-2012 (256) Cryptographic Provider;
• Signal-COM GOST R 34.10-2012 (512) Cryptographic Provider;
• Infotecs Cryptographic Service Provider.
• mode – display mode of the PIN code input window. It can take the following values:

• 0 – default mode provided by the crypto provider;
• 1 - displaying the native window of the cryptographic provider.
  Note: when working with Crypto-Pro on Linux, displaying the native window of the cryptographic provider is not available.
• 2 – displaying a window in the plugin interface.
  Note: when working with Signal-COM, displaying a window in the plugin interface is not available.

To obtain keys from the Windows system storage, specify as a provider , and the mode is My.
An example of initiating all modules:

Plugin.initPKCS11(["ISBC ESMART", "Aladdin R.D. Unified JaCarta", "Rutoken", "SafeNet", "capi:Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider,0:Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider,0:Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider,0:Signal-COM CPGOST Cryptographic Provider,0:Signal-COM GOST R 34.10-2012 (256) Cryptographic Provider,0:Signal-COM GOST R 34.10-2012 (512) Cryptographic Provider,0:Infotecs Cryptographic Service Provider,0: ,My"])

An example of initiating a module to get keys from the Windows system storage:

Plugin.initPKCS11(["capi: ,My"])

Upon successful initialization, the function returns an object (hereinafter, using the promise mechanism) that has the modules and getCertsForSign functions.

Viewing the list of modules and their status

To view the list of modules and their status, call the modules function.
Request example:

Pkcs11.modules.then(onFulfilled, onRejected);

An example of a function response (breaks are given for readability):

[ ( "enable": true, "name": "Aladdin R.D. Unified JaCarta" ), ( "enable": true, "name": "Rutoken ECP" ), ( "enable": false, "error": "100 :failed to load p11 module", "name": "ISBC ESMART" ) ]

Viewing the list of certificates

To view the list of discovered certificates, call the getCertsForSign function. As a function call parameter, you must specify whether to use the parallel mode of polling initialized PKCS#11 modules:

• true– parallel access to modules (recommended mode);
• false- Sequential access to modules.

Viewing information about a specific certificate

To view data about a particular certificate, you need to call the full_info property, which returns information about the certificate as a json object. It includes the following options:

• sn – serial number certificate
• subject- data on the subject to which the certificate was issued electronic signature. Returned as json in the "parameter: value" format, where the parameter is the name of the corresponding object identifier (OID). All standard object identifiers are given common designations, such as CN (Common Name).
• issuer– data on the issuer of the electronic signature key certificate. Returned as json in the "parameter: value" format, where the parameter is the name of the corresponding object identifier (OID). All standard object identifiers are given common designations;
• not_before– certificate validity start time (data type – string in ASN1_TIME format);
• not_after– certificate expiration time (data type – string in ASN1_TIME format);
• key_usage– information about the purpose of the key, returned as an array.

Viewing data on the electronic signature key

To view data about a specific certificate electronic signature key, you must call the token_info method. The method returns a json object with the following data:

• label– name of the key container of the electronic signature facility;
• manufacturerID– identifier of the manufacturer of the electronic signature;
• model– model of electronic signature means;
• serialNumber– serial number of the electronic signature tool.

Signing operation with the selected certificate

Simple signing mode

To sign a string using the selected certificate, you must call the cms_sign_on_it function, which takes the following input parameters:

• signature line;
• signature type - whether the signature is attached (must be passed true) or detached (false).

Advanced signing mode

Advanced mode allows you to:

• sign large volume data, such as files;
• sign multiple files without re-requesting the pin code.

To sign data with the selected certificate, you must first initialize the signer object using the start_signing function on the certificate object. Function parameters:

• signature type - whether the signature is attached (it is necessary to pass the value true) or detached (false);
• the number of attempts to enter a pin code (for example, the value "1" means that the user has only one attempt, after which the function returns an error).

Methods will be available on the signer object:

• add_data_in_hex(hexDataString) - accepts data as input in the form of a hex string;
• add_data_in_base64(base64DataString) - accepts data as input in the form of a base64 string;
• add_data_in_string(stringData) - accepts data as input in the form of a utf-8 string;
• free() - returns true/false , which allows you to check that the certificate is ready to be signed. It is required to be used for the case when several signature iterations are carried out on different certificates. In other words, if you are signing sequentially on multiple certificates, you must call this method before signing and make sure it returns true ;
• finish() - finalizes the signature and returns it in CAdES-BES / PKCS#7 format.

Line signing

An example of a command that allows you to sign a string:

Signer.add_data_in_string("1234").then(function(res)( return signer.finish();)).then(function(cms)(console.log(cms)));

In this command, "1234" is the string to be signed.

Setting multiple signatures

After the signature is finalized, the signer object is returned to the initial state. Within a session, it can be reused to sign other data, such as a new file. In this case, the pin code will not be requested again.

To sign on a different certificate, the signer object must be cleared. In most browsers, this object is cleared automatically when it leaves the scope. However, in Internet Explorer there may be situations where the clearing of the signer does not occur, resulting in an error. To avoid the error, it is recommended to explicitly clear signer.free() . This operation can be run across all browsers to unify the code. An example of signing a certificate with clearing the signer object:

Function sign(cert, info) ( function successCms(signature) ( alert(signature); ) cert.start_signing(false, 3) .then(function(signer) ( signer.add_data_in_base64("MTIzNDU2") .then(function() ( var data = signer.finish(); var free = signer.free(); return data; ), e) .then(successCms, e); ), e); )

Signing a large file

Function readFileByChunk(file, cbToRead, cbToFinish) ( var fileSize = file.size; var chunkSize = 1024*1024; // bytes var offset = 0; var chunkReaderBlock = null; var self = this; var readEventHandler = function(evt) ( if (evt.target.error == null) ( cbToRead(evt.target.result, offset, fileSize); offset += evt.target.result.byteLength; ) else ( console.error("Read error: " + evt .target.error); showError("Error reading file: " + evt.target.error); return; ) if (offset >= fileSize) ( cbToFinish() return; ) // to the next chunk chunkReaderBlock(offset, chunkSize , file); ) chunkReaderBlock = function(_offset, _chunkSize, _file) ( var r = new FileReader(); if (_file.slice) ( var blob = _file.slice(_offset, _chunkSize + _offset); ) else if (_file .webkitSlice) ( var blob = _file.webkitSlice(_offset, _chunkSize + _offset); ) else if (_file.mozSlice) ( var blob = _file.mozSlice(_offset, _chunkSize + _offset); ) r.onload = readEventHandler; r. readAsArrayBuffer(blob); ) // start reading the first block chunkReaderBlock(offset, chunkSize, file); )

It should be noted that since signing is performed locally, for the subsequent transfer of the file and signature selected by the user to the server, it is necessary to implement the appropriate logic on the side of the web page.

Hi all! Surely, many users could observe the error “Failed to load plugin” on their monitor screen when playing online audio, video, or when trying to start some kind of flash animation (game, banner, application, etc.). If you have landed on this page, then most likely you have seen a similar error. Today in this small instruction we will eliminate the error " Failed to load plugin» in the browser quickly and easily.

First, friends, let's figure out what a plug-in is in a browser. A plugin is, in other words, an add-on that extends the capabilities of an Internet browser. There are a huge number of plugins today, and they are all in different directions. Basic plug-ins are installed in any browser in order to correctly display web resources. If a message appears in the browser stating that the plugin could not be loaded, then most likely the problem is in Flash Player. Below we will consider several ways in which you can fix given error.

1st way. We update the Internet browser

2nd way. Clearing history in the browser

Cache - temporary browser files that store all the web components of the viewed resources (images, pages, video files, design, etc.). Thanks to the cache, the browser quickly loads the pages of previously visited sites, since the download of resource components is carried out not via the Internet, but from local disk computer.

Cookies are also temporary files that store the user's personal data (logins, passwords, site settings, etc.). When you go to any page, the browser sends all this data to the server, and therefore we can access any resource without re-entering the login and password for authorization.

So, let's clear the Cache and Cookie in our browser in order to try to resolve the error. We go to the menu, select "History".

3rd way. Disable extra plugins

If you are using Chrome, then type chrome://plugins in the address bar
If you are using Yandex, then type browser://plugins in the address bar
If you are using Opera, then type opera://plugins in the address bar
If you are using Firefox, then type about:plugins in the address bar

4th way. Reinstalling Adobe Flash Player

In programming, data initialization is an important task, because in this step we set the prerequisites for the application - attributes, required files and data, database connection, and so on.

WordPress has a fixed initialization procedure. When implementing life cycle Pages, the WordPress platform runs a ton of activities, many of which have been covered by us before. The system has a set of initialization hooks that are used to initialize the application before executing its basic functionality.

It is very important for theme developers and designers to understand exactly how hooks are used, as well as what are the most common mistakes in using initialization hooks, in order to create quality applications.

In this article, we'll cover the importance of initialization hooks in WordPress, as well as show you how to use them in a variety of situations.

Introduction to initialization hooks

WordPress offers a wide range of hooks that can be used in plugin and theme development.

In the case of a typical page request, all action hooks are executed in a specific order. In general, all hooks are executed after the base WordPress application has finished loading.

So initialization hooks are mainly used to, you might guess, initialize how they work in plugins and themes. Let's take a look at the available init hooks in WordPress in order of execution:

• Init is run after WordPress has finished loading, but before any headers are passed. In general, this hook is used by plugins to initialize the process of their work.
• widgets_init is used to register application widgets in the sidebar. The register_widget function is executed within this hook.
• admin_init is executed as the first action after the user has accessed the WordPress admin panel. In general, it is used to initialize settings specific to the admin area.

Apart from these three hooks, WordPress also has another hook called admin_bar_init which is executed after the admin bar has been initialized. The WordPress Codex does not contain a description of this hook, but it is used by only a small number of plugins.

You can learn the complete process of executing action hooks in WordPress in the codex.

WordPress executes each hook in a specific order (which is described in the codex). It is also important to consider the order in which events occur in each action hook. Let's look at the following situations to understand the difference.

Define admin_init inside the init hook

If we need to, we can define WordPress hooks within other hooks. In a typical request, the init hook is executed before the admin_init hook. Let's try to display something by placing admin_init inside the init hook:

Add_action("init", "test_init"); function test_init()( add_action("admin_init", "test_admin_init"); ) function test_admin_init() ( echo "Admin Init Inside Init"; )

After executing this code, we will get the desired output through the echo statement.

Define init inside the admin_init hook

Let's look at the code and output of the script when an earlier hook is defined in a hook that comes later in the execution order.

Add_action("admin_init", "test_admin_init"); function test_admin_init() ( add_action("init", "test_init"); ) function test_init() ( echo "Init Inside Admin Init"; )

In this case, we won't get any output - as expected - because the init hook runs before the admin_init hook, which is not allowed after the admin_init hook is defined.

As you can see, it's very important to understand how hooks are executed in order to create successful plugins. The order in which events appear is important for all WordPress hooks.

Examining the init and admin_init hooks

Among all the initialization hooks, it is very important to pay attention to init and admin_init, since these two hooks are used very often in many plugins. Using all other initialization hooks is much easier compared to these two hooks.

We will also look at the functionality of the init and admin_init hooks.

The init hook is executed on every request for both the front-end and back-end of the WordPress site.

The admin_init hook is executed after the admin section has completed its boot process. So this hook is executed for all requests to any admin page. Users must be registered in order to take advantage of this hook.

Since both of these hooks are executed on every request, we should think about the functionality based on the implementation of these hooks, as this can significantly affect the performance of the site.

How to use init hooks

Initialization hooks are often used by most of the existing WordPress plugins and they are very important for controlling the process of their execution.

WordPress doesn't tell us exactly what we should and shouldn't include; therefore, developers can make minor mistakes, which, in turn, can lead to a noticeable decrease in performance. In this section, we will show you how to effectively use the init and admin_init hooks.

Let's take a look at the best practices for using initialization hooks:

Hook init

• Custom Post Type Registration – The WordPress developers recommend using the init hook to register new custom post types.
• Initialize Plugin Configuration and Settings - Plugin configuration and configuration settings need to be defined per request, so it's good practice to put them inside this hook.
• Accessing submitted user data (using $_GET and $_POST) - we can intercept the submitted user data without using any action, however in this case it is recommended to use the init hook as it guarantees execution for each request.
• Adding new rewrite rules - we can set new rewrite rules using the init hook, however they will only work after a reset.
• Adding or removing custom actions - plugins contain many custom actions to extend functionality. There may be situations when we need to add new actions or remove old ones. In such cases, it is important to apply these actions in the init hook.
• Plugin text domain upload – WordPress supports numerous languages, and so we can upload a file containing translated strings. This should also be done in the init hook.

Hook admin_init

• Access Control - It is important to check the access rights of logged in users before allowing user access to a particular set of features and functionality. admin_init is the first action that will take place in the admin area, so we can use it to control access.
• Adding New Options - We can use this hook to add new settings or options pages to an existing WordPress options area.

There are many others possible options these hooks, however, these features have their own hooks, so you do not need to use initialization hooks.

Common Mistakes in Using Initialization Hooks

We often encounter situations where developers misunderstand the use of initialization hooks. Incorrect use of these hooks can lead to serious performance problems.

Let's identify common errors, as well as ways to work around them:

• Updating rewrite rules is a very resource-intensive operation, during which all rewrite rules are updated and reordered to add new ones or remove old ones that are not required. Many developers update rewrite rules inside init actions. This results in unnecessary performance overhead in every query. We must find a way manual update rewrite rules using buttons, or update rules for rare actions, such as saving plugin settings.

• Database access - To implement various functionality, you must have access to the database, but it is also important to prevent unnecessary database calls inside initialization hooks, since they are executed on each request. For this purpose, the ideal solution would be to bind database hooks to hooks with specific functionality, avoiding massive performance overhead.

• Performing Update Procedures - Plugins should include update procedures to update their capabilities in new versions. Typically, developers use initialization hooks to check the plugin version and existing settings before performing the update process. We can offer users to update the plugin on a separate screen instead of automatically doing checks on every request.

• Using initialization hooks instead of hooks for specific functionality is the most common mistake many developers make. WordPress has a wide range of hooks related to unique functionality. It is very important to use functional hooks to avoid conflicts and make the code extensible. Hooks like init and admin_init can be used in place of specific hooks, so many developers tend to use them without realizing the devastating effect they have.

Examples of common use cases for init and admin_init hooks by developers instead of the recommended hooks:

• admin_menu - We can add menu pages using the add_menu_page function. To create pages in the admin menu, it is recommended to use the admin_menu hook. However, many developers use the admin_init hook because it is executed after the admin_menu hook.
• wp_enqueue_scripts - The recommended way to add styles and scripts is to use the wp_enqueue_scripts hook. However, many developers use wp_enqueue_script inside the init hook to load scripts and styles.

There are a lot of similar situations where developers use a generic init hook instead of a specific hook for specific functionality, and this approach should be avoided if possible.

Conclusion

WordPress initialization hooks play a vital role in plugin and theme development. Many developers use hooks incorrectly, creating unnecessary performance overhead. In this article, we discussed the correct use of these hooks, as well as common mistakes their uses and how to get around them.

Now we can apply the same techniques to hooks used in plugins. Many plugin developers use their own action hooks to make plugins extensible. For such plugins, we can define plugin-specific initialization hooks to allow developers to "hang" initialization tasks onto predefined hooks.