2013-04-18 15:51:28 +02:00
|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
|
|
|
<HTML>
|
|
|
|
|
<HEAD>
|
2013-06-21 18:19:49 +02:00
|
|
|
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
|
2013-04-18 15:51:28 +02:00
|
|
|
<TITLE></TITLE>
|
2014-11-13 11:30:41 +01:00
|
|
|
<META NAME="GENERATOR" CONTENT="OpenOffice 4.1.1 (Unix)">
|
2013-04-18 15:51:28 +02:00
|
|
|
<META NAME="CREATED" CONTENT="20130417;16154700">
|
2014-11-13 11:30:41 +01:00
|
|
|
<META NAME="CHANGEDBY" CONTENT="Alex Peshkoff">
|
|
|
|
|
<META NAME="CHANGED" CONTENT="20141113;13254700">
|
2013-04-18 15:51:28 +02:00
|
|
|
<STYLE TYPE="text/css">
|
|
|
|
|
<!--
|
|
|
|
|
@page { margin: 0.79in }
|
|
|
|
|
P { margin-bottom: 0.08in }
|
|
|
|
|
-->
|
|
|
|
|
</STYLE>
|
|
|
|
|
</HEAD>
|
|
|
|
|
<BODY LANG="en-US" DIR="LTR">
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Firebird plugins.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
2013-04-21 04:09:45 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Since version 3, Firebird
|
2013-04-18 15:51:28 +02:00
|
|
|
supports plugins architecture. This means that for a number of
|
2013-06-21 18:19:49 +02:00
|
|
|
predefined points in Firebird code, user can write his own fragment
|
|
|
|
|
of code which will be executed when needed. Plugin is not necessarily
|
|
|
|
|
always written by user - Firebird already has a number of plugins
|
|
|
|
|
which are its native part. Moreover, as you will see later, some core
|
|
|
|
|
parts of Firebird are implemented as plugins. </FONT>
|
2013-04-18 15:51:28 +02:00
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>First of all a few words
|
2013-06-21 18:19:49 +02:00
|
|
|
about the term “plugin”. Unfortunately, it's often used
|
|
|
|
|
to define related but different things. Plugin is used to name:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<UL>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>dynamic library,
|
|
|
|
|
containing code to be loaded as plugin (often called plugin module)
|
|
|
|
|
and stored in $FIREBIRD/plugins directory;</FONT></P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>code implementing
|
2013-06-21 18:19:49 +02:00
|
|
|
plugin – slightly different from the library cause single
|
|
|
|
|
dynamic library may contain code for more than one plugin;</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>plugin's factory - an
|
|
|
|
|
object created by that code (pure virtual C++ class), creating
|
2013-04-21 04:09:45 +02:00
|
|
|
plugin instances on Firebird request;</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>instance of plugin,
|
|
|
|
|
created by factory.</FONT></P>
|
|
|
|
|
</UL>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>In most cases it's clear
|
2013-06-21 18:19:49 +02:00
|
|
|
from context what “plugin” do we talk about. If not it
|
|
|
|
|
will be clarified explicitly.</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Firebird plugin
|
|
|
|
|
architecture supports creation of any plugin type for any purpose –
|
|
|
|
|
but first of all this requires changes in Firebird code. Plugin can't
|
|
|
|
|
be added at any desired point “magically”. To be able to
|
|
|
|
|
have plugin (for example) encrypting database on the disk, Firebird
|
|
|
|
|
code should be prepared for it – must have a point from which
|
|
|
|
|
plugin is called. I.e. each version has a fixed set of plugins which
|
|
|
|
|
are supported. To add one more type, first of all Firebird code
|
|
|
|
|
should be modified. What DOES our plugin architecture – it
|
|
|
|
|
helps to make both adding new types of plugins and writing plugin
|
|
|
|
|
code simple and as universal between plugins as possible.</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Firebird 3 has a following
|
|
|
|
|
set of plugin types:</FONT></P>
|
|
|
|
|
<UL>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>user authentication
|
|
|
|
|
related: AuthServer (validates user's credentials on server when use
|
|
|
|
|
logins), AuthClient (prepares credentials to be passed over the
|
|
|
|
|
wire) and AuthUserManagement (maintains a list of users on a server
|
|
|
|
|
in a form, known to AuthServer);</FONT></P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>ExternalEngine
|
|
|
|
|
controls use of various engines, see README.external_routines;</FONT></P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>Trace plugin is known
|
2013-04-21 04:09:45 +02:00
|
|
|
from Firebird 2.5, but a way how it interacts with engine was
|
2013-04-18 15:51:28 +02:00
|
|
|
changed to match new generic rules; </FONT>
|
|
|
|
|
</P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>encrypting plugins
|
|
|
|
|
are for network (WireCrypt) and disk (DbCrypt), there is also helper
|
|
|
|
|
plugin KeyHolder, which is used to help maintaining secret key(s)
|
|
|
|
|
for DbCrypt;</FONT></P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>and probably the most
|
2013-06-21 18:19:49 +02:00
|
|
|
important kind – Provider. Firebird 3 supports providers as a
|
|
|
|
|
kind of plugins, which has nothing outstanding compared with others.
|
|
|
|
|
See README.Providers for more information about providers. </FONT>
|
2013-04-18 15:51:28 +02:00
|
|
|
</P>
|
|
|
|
|
</UL>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Plugins are using a set of
|
2013-04-21 04:09:45 +02:00
|
|
|
special Firebird interfaces (see README.interfaces about interfaces
|
|
|
|
|
in Firebird). All plugin-specific interfaces are reference counted,
|
2013-04-18 15:51:28 +02:00
|
|
|
i.e. have explicitly controlled lifetime. Interfaces are declared in
|
2014-11-13 11:30:41 +01:00
|
|
|
Interfaces.h include file. There is a simple example of writing
|
|
|
|
|
plugin module – DbCrypt_example. It does not perform any actual
|
2013-06-21 18:19:49 +02:00
|
|
|
encryption – just a sample of how to write plugin. Complete
|
|
|
|
|
instruction of how to write plugins is out of this document's scope.
|
|
|
|
|
Here is provided a short list of plugin features:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<UL>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>plugin may be written
|
2014-11-13 11:30:41 +01:00
|
|
|
using any language, supporting function pointers in a
|
|
|
|
|
structure/record (or at least arrays of function pointers);</FONT></P>
|
|
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>currently interfaces
|
|
|
|
|
description is available only for C++ language, at release time
|
|
|
|
|
plain-C and delphi/fpc descriptions will be present (you will need
|
|
|
|
|
to write your interfaces declarations generator for your language if
|
|
|
|
|
you need something else);</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>like with UDFs you
|
2014-11-13 11:30:41 +01:00
|
|
|
are free to add any reasonable code to your plugin, but pay
|
2013-06-21 18:19:49 +02:00
|
|
|
attention to word “reasonable” - asking a question from
|
|
|
|
|
plugin at server's console is hardly good idea;</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>it's OK to use
|
2013-04-21 04:09:45 +02:00
|
|
|
Firebird API calls in your plugin if needed (for example, default
|
|
|
|
|
authentication server and user manager are using Firebird database
|
2013-04-18 15:51:28 +02:00
|
|
|
to store accounts);</FONT></P>
|
2013-04-21 04:09:45 +02:00
|
|
|
<LI><P STYLE="margin-bottom: 0in"><FONT SIZE=4>additionally Firebird
|
2013-04-18 15:51:28 +02:00
|
|
|
provides a set of interfaces, helping you to configure your plugins
|
2013-06-21 18:19:49 +02:00
|
|
|
(certainly, you are not forced to use them – plugin is generic
|
2013-04-18 15:51:28 +02:00
|
|
|
code, which may use any way of providing configuration information,
|
2013-04-21 04:09:45 +02:00
|
|
|
but with standard tools you get common for the rest of Firebird
|
2013-04-18 15:51:28 +02:00
|
|
|
configuration style and sooner of all save you efforts).</FONT></P>
|
|
|
|
|
</UL>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Configuring plugins has 2
|
2013-06-21 18:19:49 +02:00
|
|
|
parts – first, engine should be instructed what plugins it
|
|
|
|
|
should load, and next plugins themselves sometimes need some
|
|
|
|
|
configuration. What plugins to be loaded is defined in main
|
|
|
|
|
configuration file – firebird.conf for each type of plugin.
|
|
|
|
|
Like any other value in firebird.conf the have defaults:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>AuthServer = Srp,
|
|
|
|
|
Win_Sspi</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>AuthClient = Srp,
|
|
|
|
|
Win_Sspi, Legacy_Auth</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>UserManager = Srp</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>TracePlugin = fbtrace</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Providers =
|
|
|
|
|
Remote,Engine12,Loopback</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCryptPlugin = Arc4</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>This provides normal
|
|
|
|
|
operation in server, client and embedded cases. If you want to add
|
2013-06-21 18:19:49 +02:00
|
|
|
other plugins, you must mention them in firebird.conf – except
|
2013-04-18 15:51:28 +02:00
|
|
|
other this is security measure to avoid loading unknown code. But
|
|
|
|
|
what does for example fbtrace mean here? Is it a name of dynamic
|
|
|
|
|
library to load? In trivial case yes, but exact answer is more
|
|
|
|
|
complicated.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>As it was already
|
2013-06-21 18:19:49 +02:00
|
|
|
mentioned, single plugin module may implement more than single
|
|
|
|
|
plugin. Moreover, single plugin may have at the same time more than
|
|
|
|
|
one configuration – and for each configuration separate
|
|
|
|
|
plugin's factory is created. Each of this 3 objects (module –
|
|
|
|
|
implementation – factory) has it's own name. Name of a module
|
|
|
|
|
is a file name of dynamic library. Plugin implementation's name is
|
|
|
|
|
one given to it by plugin developer and hard-coded inside module.
|
|
|
|
|
Factory's name by default equals to plugin implementation's name (and
|
|
|
|
|
it's factory name which is actually used in firebird.conf). Certainly
|
|
|
|
|
in typical trivial case, module contains one plugin, and that plugin
|
|
|
|
|
works with only one configuration, and all 3 names are equal, and no
|
|
|
|
|
more configuration is needed – for example libEngine12.so or
|
2013-04-18 15:51:28 +02:00
|
|
|
Engine12.dll contains implementation of provider Engine12, and
|
|
|
|
|
nothing else except record </FONT>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Providers = Engine12</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>in firebird.conf is needed
|
2013-06-21 18:19:49 +02:00
|
|
|
to load it. But if you have something complex – file will help
|
2013-04-18 15:51:28 +02:00
|
|
|
you to have such plugin factories which you really want.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>File plugins.conf has 2
|
2013-06-21 18:19:49 +02:00
|
|
|
types of records – config and plugin. Plugin record is a set of
|
2013-04-18 15:51:28 +02:00
|
|
|
rules for plugin's loading and activating. Plugin record has the
|
|
|
|
|
following format:</FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Plugin = PlugName ##
|
2013-04-18 15:51:28 +02:00
|
|
|
this is name to be referenced in firebird.conf</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>{</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Module = LibName ##
|
2013-04-18 15:51:28 +02:00
|
|
|
name of dynamic library</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>RegisterName = RegName
|
|
|
|
|
## name given to plugin by it's developer</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Config = ConfName ##
|
2013-04-18 15:51:28 +02:00
|
|
|
name of config record to be used</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>ConfigFile = ConfFile
|
|
|
|
|
## name of a file, containing plugin's configuration</I></FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>}</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>i.e. when plugin PlugName
|
2013-04-21 04:09:45 +02:00
|
|
|
is needed Firebird loads library LibName, finds in it plugin
|
2013-04-18 15:51:28 +02:00
|
|
|
registered with name RegName and passes it configuration from config
|
|
|
|
|
record ConfName or config file ConfFile (config record is used if
|
2013-04-21 04:09:45 +02:00
|
|
|
both are given). Each parameter in this record may be missing, in
|
2013-04-18 15:51:28 +02:00
|
|
|
that case the default PlugName is used. The only exception is
|
2013-06-21 18:19:49 +02:00
|
|
|
ConfigFile – by default, file with same name as module's
|
|
|
|
|
dynamic library but .conf extension is used. ConfigFile is expected
|
|
|
|
|
to have format Key=Value (like other Firebird configuration files),
|
|
|
|
|
same format is used for plugin record:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Config = ConfName</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>{</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Key1 = Value1</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Key2 = Value2</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>...</I></FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>}</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Let's have a sample.
|
|
|
|
|
Suppose some clients of your server trust wire encryption from one
|
2013-06-21 18:19:49 +02:00
|
|
|
vendor and others – from another one (and have different
|
|
|
|
|
licenses for appropriate client parts), but each vendor calls his
|
|
|
|
|
plugin BestCrypt. Certainly, first of all you have to rename
|
|
|
|
|
libraries to something like WC1 and WC2 – one can't have 2
|
|
|
|
|
files with same name in one directory. But after it, modules stop to
|
|
|
|
|
load automatically – they are not named BestCrypt any more. To
|
|
|
|
|
fix it, plugins.conf should contain something like this:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Plugin = WC1</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>{</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>RegisterName =
|
2013-04-18 15:51:28 +02:00
|
|
|
BestCrypt</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>}</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>Plugin = WC2</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>{</I></FONT></P>
|
2013-06-21 18:19:49 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>RegisterName =
|
2013-04-18 15:51:28 +02:00
|
|
|
BestCrypt</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>}</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Module names will be
|
|
|
|
|
automatically set to WC1 and WC2 and found. Certainly you may add
|
|
|
|
|
some configuration info for plugins if needed. Also don't forget to
|
|
|
|
|
modify firebird.conf:</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCryptPlugin = WC1,
|
|
|
|
|
WC2</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>After it server will
|
|
|
|
|
automatically select appropriate plugin to talk to client.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Another sample may be
|
2013-04-21 04:09:45 +02:00
|
|
|
found in distributed with Firebird plugins.conf. One of standard
|
2013-04-18 15:51:28 +02:00
|
|
|
plugins, UDR, is written to use non-default configuration. Therefore
|
|
|
|
|
module name and one configuration parameter are given explicitly.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Questions and answers.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Q. There are plugins named
|
|
|
|
|
Remote, Loopback, Arc4 in default configuration, but no libraries
|
|
|
|
|
with such names. How do they work?</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>A. That are so-called
|
|
|
|
|
'built-in' plugins. They are built into fbclient library, and
|
|
|
|
|
therefore are always present. Arrival of such plugins is due to old
|
2013-04-21 04:09:45 +02:00
|
|
|
ability to distribute windows Firebird client as single dll. It was
|
2013-04-18 15:51:28 +02:00
|
|
|
decided to keep such feature at least for a case when standard set of
|
|
|
|
|
plugins is used.</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Q. What do names of Srp
|
|
|
|
|
and Arc4 plugins mean?</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>A. Srp implements Secure
|
|
|
|
|
Remote Passwords protocol which is default way of authenticating
|
2013-06-21 18:19:49 +02:00
|
|
|
users in Firebird 3. It has efficient password’s length equal
|
|
|
|
|
to 20 bytes, resistant to most of attacks (including man in the
|
|
|
|
|
middle) and does not require exchanging any keys between client and
|
|
|
|
|
server to work. Arc4 means Alleged RC4 - an implementation of RC4
|
|
|
|
|
cypher. The advantage of SRP is that it can generate unique
|
|
|
|
|
cryptographically strong key on both client and server and it's
|
|
|
|
|
impossible to guess it capturing data transferred over the wire
|
|
|
|
|
during password validation by SRP. That key is used after SRP
|
|
|
|
|
handshake by Arc4, which makes wire encryption secure without need to
|
|
|
|
|
exchange any keys between client and server explicitly.</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>Q. And what do Win_Sspi
|
|
|
|
|
and Legacy_Auth mean?</FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>A. Windows SSPI was used
|
|
|
|
|
since FB 2.1 for windows trusted authentication. Legacy_Auth is
|
|
|
|
|
compatibility plugin. It's enabled by default on client to let it
|
2013-06-21 18:19:49 +02:00
|
|
|
connect to pre-FB3 servers. (Yes – it still transfers almost
|
|
|
|
|
plain passwords over the wire. Compatibility...) On server it works
|
|
|
|
|
with security database from FB 2.5, and should be avoided except
|
|
|
|
|
cases when you understand well what are you doing. To use Legacy_Auth
|
2014-11-13 11:30:41 +01:00
|
|
|
on server you should set lower level of network traffic encryption in
|
2013-04-18 15:51:28 +02:00
|
|
|
firebird.conf:</FONT></P>
|
2014-11-13 11:30:41 +01:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Enabled</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4>or in the worst case:</FONT></P>
|
2013-04-18 15:51:28 +02:00
|
|
|
<P STYLE="margin-bottom: 0in"><FONT SIZE=4><I>WireCrypt = Disabled</I></FONT></P>
|
|
|
|
|
<P STYLE="margin-bottom: 0in"><BR>
|
|
|
|
|
</P>
|
|
|
|
|
</BODY>
|
|
|
|
|
</HTML>
|
