?? x1740.htm
字號:
>then the data for two users <I
CLASS="EMPHASIS"
>jim@a-domain.com</I
> and
<I
CLASS="EMPHASIS"
>john@b-domain.com</I
>
would be stored as shown in <A
HREF="x1740.htm#JABTDG-CH-4-FIG-4.6"
>Figure 4-6</A
>.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-4-FIG-4.6"
></A
><P
><B
>Figure 4-6. Storage of server-side user data by hostname</B
></P
><PRE
CLASS="SCREEN"
> +--------+
| Jabber |
jim@a-domain.com ---> | Server |
| |
john@b-domain.com ---> | |
| | +-- a-domain.com/ -- jim.xml
+--------+ |
| |
+-- spool/ --+
|
+-- b-domain.com/ -- john.xml</PRE
></DIV
><P
>Although specifying multiple hostnames for the session management component
instance will effect a sort of virtual hosting, with separate data storage
as described, the rest of the features of the component will be identical.
For example, this means that the list of available services that the client
can request—the <I
CLASS="EMPHASIS"
>agent list</I
> (old terminology) or
<I
CLASS="EMPHASIS"
>browse list</I
> (new terminology)—and the session
features such as roster management, administration functions, private data
storage and so on, will be identical. If you want to offer different
services for different hostnames from the same Jabber server, see
<A
HREF="x3305.htm"
>the section called <I
>Managing the Configuration</I
></A
> later in this chapter.</P
><DIV
CLASS="CAUTION"
><P
></P
><TABLE
CLASS="CAUTION"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Hostname needed here</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>You cannot use the catchall empty
<TT
CLASS="LITERAL"
><host/></TT
>
tag for the session management component—it needs to be given an
explicit host identity in order to function.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3"
>Custom configuration</A
></H3
><P
>In <A
HREF="x1581.htm#JABTDG-CH-4-SECT-4.2.2"
>the section called <I
>A typical component instance description</I
></A
> earlier, we
described the elements in this order:
<I
CLASS="EMPHASIS"
>component type</I
>,
<I
CLASS="EMPHASIS"
>component identification</I
>,
<I
CLASS="EMPHASIS"
>host filter</I
>,
<I
CLASS="EMPHASIS"
>connection method</I
>,
<I
CLASS="EMPHASIS"
>custom configuration</I
>.
Being XML, the configuration format is flexible enough to allow us to
manage the ordering (but not the nesting!) of the configuration directives
to suit our own layout purposes. In this instance, we
come to the <I
CLASS="EMPHASIS"
>custom configuration</I
>—the
<I
CLASS="EMPHASIS"
>connection method</I
> comes afterwards.</P
><P
>The <I
CLASS="EMPHASIS"
>sessions</I
> component (i.e. the JSM) offers a lot of
facilities, which means that in order to attach an instance of the
JSM into our Jabber server we have a lot of configuring to do. </P
><P
>Our configuration wrapper tag for the JSM instance is </P
><P
><PRE
CLASS="SCREEN"
><jsm xmlns="jabber:config:jsm"></PRE
></P
><P
>The tag name "<TT
CLASS="LITERAL"
>jsm</TT
>" is simply representative of
what the configuration
pertains to; Once loaded, the JSM component will look for the
configuration by the namespace identifier
<TT
CLASS="LITERAL"
>jabber:config:jsm</TT
>.
we have different sections that approximately relate to the different
<I
CLASS="EMPHASIS"
>services</I
> that the jsm is going to provide.</P
><TABLE
CLASS="SIDEBAR"
BORDER="1"
CELLPADDING="5"
><TR
><TD
><DIV
CLASS="SIDEBAR"
><A
NAME="AEN1876"
></A
><P
><B
>Services and modules</B
></P
><P
><A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.4"
>the section called <I
>Component Connection Method</I
></A
>
describes in detail how these jsm services
are loaded. Generally, each service is represented by a tag that specifies
a library to be loaded, and the tag name is what is used to refer to the
service, thus giving it a name.</P
><P
>For example, the <I
CLASS="EMPHASIS"
>echo</I
> service, which is used
to test the Jabber server (any message sent to a special echo address
<TT
CLASS="LITERAL"
>servername/echo</TT
>, which is the servername with
a resource of "echo", will be echoed back to the sender) is loaded in the
<TT
CLASS="LITERAL"
><mod_echo/></TT
> tag and is referred
to as the <I
CLASS="EMPHASIS"
><TT
CLASS="LITERAL"
>mod_echo</TT
> module</I
>.
So it can be said that the <TT
CLASS="LITERAL"
>mod_echo</TT
>
<I
CLASS="EMPHASIS"
>module</I
>
provides the echo <I
CLASS="EMPHASIS"
>service</I
>. </P
></DIV
></TD
></TR
></TABLE
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3.1"
>Filter Service</A
></H4
><P
>The message filter service, provided by the
<TT
CLASS="LITERAL"
>mod_filter</TT
> module
allows clients to set up mechanisms that can control and manage incoming
messages as they arrive at the recipient's Jabber server—before
they start on the final leg of the journey to the recipient's client.</P
><P
>The service allows each user to maintain their own filter, which is a
collection of <I
CLASS="EMPHASIS"
>rules</I
>.
A rule is a combination of conditions and actions.
For each incoming message, the message filter service kicks in and goes
through the rules contained in the message recipient's filter one by one,
checking the characteristics of the incoming message using the conditions
defined in each rule. If one of the conditions matches, then the action
or actions defined in that rule are carried out and the message filter
service stops going through the rules—unless the action specified is
'continue'—in which case the service goes on to the next rule. The
'continue' action makes it possible to chain together a complex series of
checks and actions.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-4-FIG-4.7"
></A
><P
><B
>Figure 4-7. A message filter</B
></P
><PRE
CLASS="SCREEN"
> +-----------------------------------------+
| filter |
| +-------------------------------------+ |
| | rule | |
| | +-----------+ +-----------+ | |
| | +-----------+ | +-----------+ | | |
| | | condition | | --> | action | | | |
| | | | + | | + | |
| | +-----------+ +-----------+ | |
| +-------------------------------------+ |
| |
| +-------------------------------------+ |
| | rule | |
| | +-----------+ +-----------+ | |
| | +-----------+ | +-----------+ | | |
| | | condition | | --> | action | | | |
| | | | + | | + | |
| | +-----------+ +-----------+ | |
| +-------------------------------------+ |
| |
| ... |
| |
+-----------------------------------------+ </PRE
></DIV
><P
>Each user's filter is stored on the server using the <I
CLASS="EMPHASIS"
>xdb</I
>
component (see later).
What does a typical filter look like? Well, <A
HREF="x1740.htm#JABTDG-CH-4-EX-9"
>Example 4-9</A
>
shows a filter that contains two rules -</P
><P
></P
><UL
><LI
><P
>Rule "holiday" checks the message recipient's presence
and sends a 'holiday' notice back if the presence is set to 'Extended Away',
and forwards the incoming message to a colleague.</P
></LI
><LI
><P
>Rule "custreply" checks to see
if the message is from someone that exists in certain groups in the
recipient's roster and if so sends an auto-reply to that person, sets the
incoming message type to 'normal' (in case it was a 'chat' message), and
allows the message to reach its original intended destination.</P
><P
>This could
be useful in a customer support scenario where the support representative
could handle incoming queries in a queue of 'normal' messages but have an
auto-reply sent out for each query telling the customer that their request
will be dealt with shortly.</P
></LI
></UL
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-4-EX-9"
></A
><P
><B
>Example 4-9. A message filter with two rules</B
></P
><P
><PRE
CLASS="SCREEN"
><query xmlns="jabber:iq:filter">
<rule name="holiday">
<show>xa</show>
<reply>I'm on holiday - back on the 25th!</reply>
<forward>mycolleague@yak</forward>
</rule>
<rule name="custreply">
<group>CustomersNorth</group>
<group>CustomersSouth</group>
<reply>Thanks - an operator will attend to you shortly</reply>
<continue/>
</rule>
</query></PRE
></P
></DIV
><P
>Note that there is no nesting or grouping to distinguish conditions from
actions. In the first rule - "holiday" - there is one condition (
<TT
CLASS="LITERAL"
><show/></TT
>
) and two actions (
<TT
CLASS="LITERAL"
><reply/></TT
>
and
<TT
CLASS="LITERAL"
><forward/></TT
>
) and in the second rule - "custreply" - there are two conditions
(two <TT
CLASS="LITERAL"
><group/></TT
>s)
and two actions (
<TT
CLASS="LITERAL"
><reply/></TT
>
and
<TT
CLASS="LITERAL"
><continue/></TT
>
).</P
><P
>There are a few things to note from this example:</P
><P
>The <TT
CLASS="LITERAL"
><continue/></TT
>
action means that the filter checking will move on to the 'next rule'
which doesn't exist, meaning that the original message will still be
delivered. No
<TT
CLASS="LITERAL"
><continue/></TT
>
would have meant that the message would have been dropped (that is, it
wouldn't have reached it's final original destination) - because when
a rule matches the actions in that rule are carried out and a successful
delivery is implied. </P
><P
>The conditions are ORed
together, that is to say if <I
CLASS="EMPHASIS"
>any</I
> of the conditions
in a rule match then the rule has matched and all of actions defined in
the rule are carried out.</P
><P
>So with this in mind, let's examine the message filter service configuration:</P
><P
><PRE
CLASS="SCREEN"
><filter>
<default/>
<max_size>100</max_size>
<allow>
<conditions>
<ns/>
<unavailable/>
<from/>
<resource/>
<subject/>
<body/>
<show/>
<type/>
<roster/>
<group/>
</conditions>
<actions>
<error/>
<offline/>
<forward/>
<reply/>
<continue/>
<settype/>
</actions>
</allow>
</filter></PRE
></P
><P
>Within the <TT
CLASS="LITERAL"
><filter/></TT
>
configuration wrapper, we have three children:</P
><P
><I
CLASS="EMPHASIS"
><TT
CLASS="LITERAL"
><default/></TT
></I
></P
><P
>The <TT
CLASS="LITERAL"
><default/></TT
> tag
allows the server administrator to specify default filter rules that
will be applied for every user registered on that Jabber server.
Specifying something like this:</P
><P
><PRE
CLASS="SCREEN"
><default>
<rule name="server wide rule">
<from>spammer@spamcity.com</from>
<error>No spam please, we're British!</error>
</rule>
</default></PRE
></P
><P
>will effectively filter out all messages from our friendly spammer.</P
><P
>The rules specified in the
<TT
CLASS="LITERAL"
><default/></TT
> tag will be
<I
CLASS="EMPHASIS"
>appended</I
> to any personal rules the user may have
defined himself. This is important when you consider the order in which
the rules are tested, and that once a rule is matched, filter processing
stops (unless the
<TT
CLASS="LITERAL"
><continue/></TT
>
action is used).</P
><P
><I
CLASS="EMPHASIS"
><TT
CLASS="LITERAL"
><maxsize/></TT
></I
></P
><P
>Filter rule matching is expensive. We don't want to allow the user to
go overboard with filter rules - we can place an upper limit on the number
of rules in a filter with the
<TT
CLASS="LITERAL"
><maxsize/></TT
> tag.
(The default is rather large - anyone who can be bothered to create
100 rules deserves to have them all checked, in my opinion!)</P
><P
><I
CLASS="EMPHASIS"
><TT
CLASS="LITERAL"
><allow/></TT
></I
></P
><P
>The <TT
CLASS="LITERAL"
><allow/></TT
> tag specifies
the <TT
CLASS="LITERAL"
><conditions/></TT
>
and <TT
CLASS="LITERAL"
><actions/></TT
>
that a user is allowed to use in building rules.
<A
HREF="x1740.htm#JABTDG-CH-4-TABLE-1"
>Table 4-1</A
> and
<A
HREF="x1740.htm#JABTDG-CH-4-TABLE-2"
>Table 4-2</A
>
show the possible filter conditions and actions.</P
><DIV
CLASS="TABLE"
><A
NAME="JABTDG-CH-4-TABLE-1"
></A
><P
><B
>Table 4-1. Filter conditions</B
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><THEAD
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -