Oauth tokens can be generated for commands (scopes) having admin|user|open
policy. Restricted commands are not available as those are only usable
from ejabberdctl command line.
Four new commands are available:
$ejabberdctl oauth_issue_token "stats;get_roster"
Generates a token authorized to call both stats and get_roster
commands. Note scopes must be separated by semicolon.
$ejabberdctl oauth_list_tokens
List tokens generated from the command line, with their scope
and expirity time.
$ejabberdctl oauth_list_scopes
List scopes available
$ejabberdctl oauth_revoke_token "Lbs7qdJfdKXOWzVrArgyckY055tE1xnt"
Revokes the given token
Let jlib:is_standalone_chat_state/1 unwrap carbon copies rather than
leaving this to the caller. We still export jlib:unwrap_carbon/1, as
this function might also be useful for other purposes.
Let mod_client_state simply queue the most recent item of a given PEP
node (from a given contact) instead of also taking the payload namespace
into account.
Don't hold back (carbon copies of) chat states from other resources, as
they might be used to sync the state of conversations across clients.
E.g., if one client becomes active, another one might want to remove a
notification (immediately).
Add code necessary to support publishing options as described in
XEP-0060, #7.1.5. A node plugin that expects publishing options must
add <<"publish-options">> to the features/0 list and then handle the
publishing options handed over to the publish_item/7 call.
Signed-off-by: Christian Ulrich <christian@rechenwerk.net>
Don't write MAM messages into an Mnesia archive if the size of the table
comes close to the 2 GB limit for tables with disc-only copies. That
way, the table is at least not corrupted when the limit is reached.
Let mod_mam_mnesia use transactions when storing or deleting messages.
If old messages of a user are to be removed, delete the user's archive
and rewrite it from scratch, as that seems to be much faster than
removing individual records with delete_object/1.
Closes#1065.
Notify the current room occupants if the affiliation of a non-occupant
is changed as per example 195 of XEP-0045. In anonymous rooms, only
moderators are notified, though.
If the new "queue_pep" option is enabled and the client is inactive, PEP
notifications are throttled in a similar way to presence stanzas and
chat states. Only the most recent notification of a given node and
payload type will be queued from a given contact.
Let mod_client_state handle the queueing of stanzas, not just their
classification. This simplifies the ejabberd_c2s code and gives
(custom) CSI modules more flexibility.
- Change order of the hooks in mod_mam for sending and receiving packets. Messages are archived before a carbon copy is send to the other recourcces.
- Add archived tag and unique stanza id to the outgoing packet to have message carbons with the archive information.
- Add additional hook (in mod_mam) to strip the archive tag for outgoing packets after message carbons have been send.
Let the main mod_http_upload process look at the size of an HTTP upload
rather than performing this check in the ejabberd_http handler. This
way, the upload slot won't be invalidated if the size of the uploaded
file doesn't match the size requested for the slot. The PUT request is
still rejected, but the client now has a chance to retry the upload.
The test suite sends messages to the server JID while checking whether
the stream management code counts outgoing stanzas correctly. We now
set type='headline' for those messages to avoid error bounces.
When stanzas are bounced from the stream management queue (because the
session timed out or was closed for some other reason), use a different
error message so that this situation can be distinguished from other
cases.
We no longer rely on getting unique values from clock source, so we need
to handle cope with systems which does not have a microsecond resolution
on system clock (such as MS Windows)
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming last activity query was blocked by a privacy list (just as we
do for other IQ requests).
If an incoming message sent to an unavailable resource has an unknown
type, handle it like messages of type "normal" (as mandated by RFC 6121,
section 5.2.2). The same is already done for messages of unknown type
sent to the bare JID of an offline user.
Don't bounce an error when a message of type "headline" is sent to an
unavailable resource. This is consistent with how headline messages
sent to the bare JID of an offline user are dropped, and it avoids a
presence leak.
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming message sent to an offline user was blocked by a privacy list.
The same is done for a message sent to an online user, so this avoids a
presence leak.
We need to be able to run only a few test groups, even if we do not have all
database backends installed and configured locally.
ejabberd test suite configures a specific host per backend. I changed ejabberd
to allow ignoring some hosts from config file on start, by providing the exact
list of hosts we want to start.
This is done by setting an ejabberd app Erlang environment variable 'hosts' and
passing the list of hosts we want to actually define.
When doing so, the backend specific hosts defined in ejabberd test configuration file
are simply ignored. As a result, we do not try to connect to unavailable backends.
I linked that part to CT run test by defining the hosts list based on environment variable
CT_BACKENDS. This variable is expected to be a comma separated list of available backends.
When Erlang Common Tests are run with that environment variable set, only the host matching
the name of the backend will be set, plus the default "localhost", common to many tests.
This can be combined with rebar ct groups list.
Example commands to run tests:
CT_BACKENDS=riak,mnesia rebar ct suites=ejabberd
CT_BACKENDS=mnesia rebar ct suites=ejabberd groups=mnesia
The send_update_presence/4 function already checked whether the room is
overcrowded before calling send_update_presence1/4, so there's no need
to have send_new_presence/4 perform the same check.
XEP-0313 says: "A MUC archive MUST check that the user requesting the
archive has the right to enter it at the time of the query [...]. In
the case of open MUC rooms, the MUC archives can generally be accessed
by any users [...] who do not have an affiliation of 'outcast'".
If the "resend_on_timeout" option is set to 'if_offline' and a pending
stream management session is terminated because a new session is opened
by the same resource (while no other resource is online), resend
unacknowledged messages rather than bouncing error messages.
Include the occupant JID with MUC MAM messages if the room is not
anonymous, and also when the MAM user sent the MUC message himself (not
just in the case where he is a room moderator).
Strip any pre-existing <x/> tags which have an <item/> child with a
'jid' attribute from MUC MAM messages. This way, if such a tag exists,
clients can be sure it was added by mod_mam.
If a stream management session times out for a user who appears to be
using MAM, drop any unacknowledged messages rather than resending or
bouncing them. This avoids duplicates or bogus error messages.
However, this is only done if the new mod_mam option "assume_mam_usage"
is set to 'if_enabled' or 'on_request'. In the former case, a user is
assumed to be using MAM if archiving is enabled for his account. In the
latter case, MAM usage is assumed only if archiving was explicitly
requested by the client, or if archiving was enabled by means of
mod_mam's "request_activates_archiving" option.
Sort the messages retrieved from an Mnesia archive before selecting the
subset limited by the <max/> value. This makes sure the desired subset
of messages is sent to the client.
If the client doesn't specify a maximum number of messages to retrieve
per page, set a limit of 50 messages. If the client specifies a limit
larger than 250, cap the number to 250 messages.
These limits aren't enforced for MAM v0.2 requests though, as that
version of the XEP doesn't require clients to support RSM. The newer
revisions say that "a server MAY place a reasonable limit on how many
stanzas may be pushed to a client in one request. Whether or not the
client query included a <set/> element, the server MAY simply return its
limited results, modifying the <set/> element it returns appropriately."
If an <index/> is specified in the MAM request, reject the request
rather than ignoring the desired index and returning wrong results.
XEP-0059 says that the server "MAY return a <feature-not-implemented/>
error."
Make sure the binary comparison performed when clients use message UIDs
to page through Mnesia archives yields correct results even if the
specified UIDs don't have the same number of digits as the UIDs of the
stored messages. This way, MAM will continue to work as expected after
migrating from mod_mam_mnesia to mod_mam.
The new "delete_old_mam_messages" command allows for purging all MAM
messages of the specified type older than the specified number of days.
(Currently only implemented for Mnesia archives.)
Enabling "request_activates_archiving" tells mod_mam not to store any
messages for a user until his client issued a MAM request, regardless of
mod_mam's "default" option. Once a MAM request is issued, messages are
archived as usual.
If a message stanza is blocked as per XEP-0016 or XEP-0191, return an
error only if the type of the blocked message is "normal" or "chat".
This makes sure users won't be kicked from MUC rooms when blocking other
participants.
Closes#897.
Don't just use the "put_url" domain name, but also any path components
of the specified URL, to generate a mod_http_upload process name. This
way, a single domain name can be used for multiple virtual hosts by
specifying a "put_url" such as "https://example.com/@HOST@/".
Use <stanza-id/> elements instead of <delay/> tags to check for messages
resent by the stream management code. The <stanza-id/> element is
preferable, as it is added by mod_mam itself.
This option make 'rebar get-deps' command to always fetch latest versions
of deps that are developed together with ejabberd instead of using frozen
commit/branch/tag.
Specifying "--enable-nif" or "--disable-nif" when running ejabberd's
configure script has no effect anymore: NIF support is enabled by
default and can only be disabled by building the p1_xml dependency with
"--disable-nif".
As per XEP-0313 version 0.2 and newer, advertise the MAM feature in the
service discovery information for the bare account (or MUC room) JID.
Some clients check the server's discovery information instead, so we'll
continue to advertise the feature there as well.
Mysql 'utf8' do not support 4-bytes UTF8 chars.
Characters like 'KISS MARK' (U+1F48B) causes mysql
to cut the string at that point.
There is utf8mb4 encoding available on newer mysql
versions that do support 4-bytes utf8. But for storing
stanzas, that doesn't need to be indexed or searched or
inspected in any way, it was easier to use BLOB
(the bytes stored are utf8 encoded anyway, like all XMPP),
and avoids the need to redefine indexes (as allowed size
is shorter on utf8mb4) or having mixed utf8 and utf8mb4
encodings on the same table.
Make sure the "reopen_log" command really just reopens log files without
also rotating them. For rotating log files, the new "rotate_log"
command can be used.
When sending the room subject to a new participant, always use the
occupant JID that corresponds to the subject author as the 'from'
address. It was already done this way when the subject was sent as part
of the room history.
Log an [info] message if a PUT request looks like the specified
"put_url" contains a path component that doesn't match the
"request_handlers" path, as in the following configuration:
listen:
-
module: ejabberd_http
port: 5444
request_handlers:
"/": mod_http_upload
modules:
mod_http_upload:
put_url: "http://example.com/path/"
Let identify/1 return 'pass' when it failed to identify the file type,
as this doesn't (necessarily) indicate an error condition. This also
makes it consistent with the return value of convert/2.
The mod_http_upload_quota module attempts to delete a directory whenever
it removes a file from that directory. However, if thumbnail creation
is enabled, directories will often contain two files. Therefore, don't
log an info (but only a debug) message if directory removal fails.
Don't log an error (but only a debug) message if ImageMagick fails to
indentify the file type for thumbnail creation. The image might be
encrypted, or it could be a non-image file.
Closes#809.
mod_http_upload_quota implements two features:
- When a "hard quota" is exceeded during a file upload, old files are
removed until the disk usage equals or falls below the "soft quota".
- Once a day, all uploaded files (and directories) older than a
configurable number of days are deleted.
The stop/1 function now terminates stream management sessions
immediately, just as it does for other sessions. The new
ejabberd_c2s:close/1 function can be used to close the socket without
terminating the stream management session, like stop/1 did before.
Our new nif xml parser don't handle this gracefully, so we better don't
call it that way.
This is only triggered on old style ssl sockets, where ssl layer must
be activated early, before association between socket and c2s is
established
When an XEP-0198 session times out, always return an error for
unacknowledged IQ stanzas, and always drop presence stanzas. That is,
the "resend_on_timeout" option no longer applies to those stanzas types,
but only to messages.
In the past, the "resume_timeout" option defined both the default resume
timeout and the maximum resume timeout clients are permitted to request.
Admins might want to allow clients to request a timeout value that's
larger than the default, though. This can now be done by specifying the
"max_resume_timeout" option.
Before this having listeners on same port for both tcp and udp would after
config merging step left only one of them.
Many thanks to Holger Weiß for noticing this.
With this commit, arguments change in two commands:
* destroy_room: does not require Host argument
* send_direct_invitation: instead of Room, now requires Name and Service
- catch exceptions
- do ets:give_away for multicastp table on init
- don't send multicasts to itself
- don't check user@server for multicast support
- handle empty disco items
- ignore cdata in <addresses/>
- properly check for subdomains
This is a convenience reverse of make_jid/1. It allows extracting the jid parts
without relying on using the jid record structure, to abstract details.
Don't carbon-copy messages of type "normal" that don't have a body
element as an immediate subtag. Those messages are usually generated by
clients or servers (as opposed to messages written by humans). This
includes MAM messages, for example.
Check for the <no-storage/> and <no-permanent-storage/> hints in
addition to <no-store/> and <no-permanent-store/>. XEP-0334 (0.1)
mentions both variants, and unfortunately, both of them are in use.
Either contributed module include dependencies this way
deps/
dep1/
src/
include/
dep1/
src/
include/
Or includes rebar.config or rebar.config.script:
In this case, only git is supported (if git command available)
and ext_mod checkout code in deps directory.
In both case, only basic built procedure is supported. ext_mod
does not do more than bare compilation like this:
erlc -I include src/*erl
Let mod_pubsub send last items whenever a contact updates the entity
capabilities. This was already done for remote contacts and is now also
done for local contacts.
During login, clients might receive a relatively large number of stanzas
in one go. For some users, the default value of the "max_ack_queue"
option turned out to be too small in that situation.
Generated the mix.exs file through configure is not possible when using mix, as
it does not run configure after having downloaded the dependencies.
#621
Previous versions of XEP-0045 suggested sending a warning message to new
occupants of a non-anonymous MUC room. The current revision (1.25) says
that a status code of "100" must be returned with the user's initial
presence, instead. We already do this (in addition to generating the
warning message).
Receiving the warning message each time the client joins the room can
become annoying, especially when reconnections occur frequently (e.g.,
on mobile devices). So, we omit it, now.
Specify settings that make sense with current ejabberd versions, and use
the YAML configuration format. Also, specify the "urn:xmpp:microblog:0"
namespace, as that's the microblogging node name currently defined by
XEP-0277.
Don't just check whether the full JID is subscribed when a node
subscription is required to list or publish items. If the bare JID is
subscribed, these requests are now also accepted.
Let send_text/2 and (therefore) send_element/2 return {error, Reason}
instead of error for consistency, and let send_stanza_and_ack_req/2
interpret any non-ok value as an error. (EJAB-1739)
This allows the authentication modules to perform SASL proxy authentication. It puts the onus on them to authorize the authcid to masquerade as the authzid. Doesn't currently implement such functionality in existing auth modules, since they cannot currently codify a relationship between the two identities. Does not permit the authzid to use a domain differently from the one of the connection.
Note: digest might not work, but I have no interest in it, being deprecated.
In addition to factorize how the mnesia dir option is given to erl
commands, it allows one to set extra mnesia options via the
MNESIA_OPTIONS environment variable.
As a small optimization, avoid running the 'roster_get' hook in the
(common) case where a client requests service discovery information for
its own bare JID.
Don't swap the sending and receiving JIDs while checking whether the
client that requested service discovery information for a bare account
JID is a subscribed contact.
Make sure the server processed the slave's active request after the
previous test stanzas were received by the slave and before the final
Chat State notification is sent by the master.
For couple years browsers did limit ability to change cookies from js
for different domains, this made http_poll connections practically not
usuable. I don't think this module is used at all so it's time to put it
to rest.
Old style websocket do use binaries for transferring data to C2S, so when
we buffer that data we need to handle it different than list of #xml structs
used by new style connections.
This fixes github issue #515.
RFC 6455 says that the client's opening handshake includes an Upgrade
header field "containing the value 'websocket', treated as an ASCII
case-insensitive value."
Closes#510.
Previous commits were done with:
for i in `git log --reverse --date-order --format=%h mod_admin_extra.erl`; do git format-patch -1 $i; cat 00* >>patch; rm 00*; done
Then editing patch to remove unneeded files and fix path.
As per RFC 6121, deliver headline messages that were sent to a bare JID
to all resources with a non-negative priority, not just to those with
the highest priority. If no such resource is available, discard them
silently.
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming message was blocked by a privacy list. This lets the user
appear offline to the contact.
The jlib:rsm_decode/1 function sets the 'max' and/or 'index' elements of
the returned 'rsm_in' record to 'error' if the parsed strings cannot be
converted to integer values.
This is a preliminary version that is tested to work with the packaging
branch of ejabberd-modules repository
This version lacks automatic configuration include at runtime
As per version 1.25 of XEP-0045, use the room JID as the 'from' address
for <delay/> elements also when the room is non-anonymous, and specify
the original JID of the sender as an XEP-0033-style tag instead.
Closes#465.
Before generating a carbon copy for a resource, make sure it's actually
available. This handles the case where, for some reason, the
'unset_presence_hook' wasn't called during logout of a resource. Carbon
copies sent to that resource would otherwise be re-routed to another
resource (which might've received a copy of that message already).
If the "captcha_host" is specified without "http://" or "https://"
prefix, ejabberd_captcha tries to figure out the protocol automatically.
Fix the code that parses the listener configuration in order to do that.
Allow temporary processes to perform some final actions when shutting
down. For example, moc_muc_room:terminate/3 fails to send 'unavailable'
presence to the room participants when killed immediately.
Let add_message_type/2 accept the type as an atom, and let the function
handle the 'normal' message type. This doesn't change the behavior, but
avoids some code duplication.
</p><p><spanstyle="font-family:monospace">ejabberd</span> is a free and open source instant messaging server written in <ahref="http://www.erlang.org/">Erlang/OTP</a>.</p><p><spanstyle="font-family:monospace">ejabberd</span> is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.</p><p><spanstyle="font-family:monospace">ejabberd</span> is designed to be a rock-solid and feature rich XMPP server.</p><p><spanstyle="font-family:monospace">ejabberd</span> is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.</p>
<!--TOC section id="sec2" Key Features-->
<h2id="sec2"class="section">1  Key Features</h2><!--SEC END --><p>
<aid="keyfeatures"></a>
</p><p><spanstyle="font-family:monospace">ejabberd</span> is:
</p><ulclass="itemize"><liclass="li-itemize">
Cross-platform: <spanstyle="font-family:monospace">ejabberd</span> runs under Microsoft Windows and Unix derived systems such as Linux, FreeBSD and NetBSD.</li><liclass="li-itemize">Distributed: You can run <spanstyle="font-family:monospace">ejabberd</span> on a cluster of machines and all of them will serve the same Jabber domain(s). When you need more capacity you can simply add a new cheap node to your cluster. Accordingly, you do not need to buy an expensive high-end machine to support tens of thousands concurrent users.</li><liclass="li-itemize">Fault-tolerant: You can deploy an <spanstyle="font-family:monospace">ejabberd</span> cluster so that all the information required for a properly working service will be replicated permanently on all nodes. This means that if one of the nodes crashes, the others will continue working without disruption. In addition, nodes also can be added or replaced ‘on the fly’.</li><liclass="li-itemize">Administrator Friendly: <spanstyle="font-family:monospace">ejabberd</span> is built on top of the Open Source Erlang. As a result you do not need to install an external database, an external web server, amongst others because everything is already included, and ready to run out of the box. Other administrator benefits include:
<ulclass="itemize"><liclass="li-itemize">
Comprehensive documentation.
</li><liclass="li-itemize">Straightforward installers for Linux, Mac OS X, and Windows. </li><liclass="li-itemize">Web Administration.
</li><liclass="li-itemize">Shared Roster Groups.
</li><liclass="li-itemize">Command line administration tool. </li><liclass="li-itemize">Can integrate with existing authentication mechanisms.
</li><liclass="li-itemize">Capability to send announce messages.
</li></ul></li><liclass="li-itemize">Internationalized: <spanstyle="font-family:monospace">ejabberd</span> leads in internationalization. Hence it is very well suited in a globalized world. Related features are:
<ulclass="itemize"><liclass="li-itemize">
Translated to 25 languages. </li><liclass="li-itemize">Support for <ahref="http://www.ietf.org/rfc/rfc3490.txt">IDNA</a>.
</li></ul></li><liclass="li-itemize">Open Standards: <spanstyle="font-family:monospace">ejabberd</span> is the first Open Source Jabber server claiming to fully comply to the XMPP standard.
</li><liclass="li-itemize">ODBC data storage support.
</li><liclass="li-itemize">Microsoft SQL Server support. </li><liclass="li-itemize">Riak NoSQL database support.
</li></ul>
</li><liclass="li-itemize">Authentication
<ulclass="itemize"><liclass="li-itemize">
Internal Authentication.
</li><liclass="li-itemize">PAM, LDAP, ODBC and Riak. </li><liclass="li-itemize">External Authentication script.
</li></ul>
</li><liclass="li-itemize">Others
<ulclass="itemize"><liclass="li-itemize">
Support for virtual hosting.
</li><liclass="li-itemize">Compressing XML streams with Stream Compression (<ahref="http://www.xmpp.org/extensions/xep-0138.html">XEP-0138</a>).
</li><liclass="li-itemize">Statistics via Statistics Gathering (<ahref="http://www.xmpp.org/extensions/xep-0039.html">XEP-0039</a>).
</li><liclass="li-itemize">IPv6 support both for c2s and s2s connections.
</li><liclass="li-itemize"><ahref="http://www.xmpp.org/extensions/xep-0045.html">Multi-User Chat</a> module with support for clustering and HTML logging. </li><liclass="li-itemize">Users Directory based on users vCards.
</li><liclass="li-itemize"><ahref="http://www.xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a> component with support for <ahref="http://www.xmpp.org/extensions/xep-0163.html">Personal Eventing via Pubsub</a>.
</li><liclass="li-itemize">Support for web clients: <ahref="http://www.xmpp.org/extensions/xep-0025.html">HTTP Polling</a> and <ahref="http://www.xmpp.org/extensions/xep-0206.html">HTTP Binding (BOSH)</a> services.
</li><liclass="li-itemize">IRC transport.
</li><liclass="li-itemize">SIP support.
</li><liclass="li-itemize">Component support: interface with networks such as AIM, ICQ and MSN installing special tranports.
</li></ul>
</li></ul>
<!--TOC section id="sec4" How it Works-->
<h2id="sec4"class="section">3  How it Works</h2><!--SEC END --><p>
<aid="howitworks"></a></p><p>A XMPP domain is served by one or more <spanstyle="font-family:monospace">ejabberd</span> nodes. These nodes can
be run on different machines that are connected via a network. They all must
have the ability to connect to port 4369 of all another nodes, and must have
the same magic cookie (see Erlang/OTP documentation, in other words the file
<spanstyle="font-family:monospace">~ejabberd/.erlang.cookie</span> must be the same on all nodes). This is
needed because all nodes exchange information about connected users, S2S
connections, registered services, etc…</p><p>Each <spanstyle="font-family:monospace">ejabberd</span> node have following modules:
</p><ulclass="itemize"><liclass="li-itemize">
router;
</li><liclass="li-itemize">local router.
</li><liclass="li-itemize">session manager;
</li><liclass="li-itemize">S2S manager;
</li></ul>
<!--TOC subsection id="sec5" Router-->
<h3id="sec5"class="subsection">3.1  Router</h3><!--SEC END --><p>This module is the main router of XMPP packets on each node. It routes
them based on their destinations domains. It has two tables: local and global
routes. First, domain of packet destination searched in local table, and if it
found, then the packet is routed to appropriate process. If no, then it
searches in global table, and is routed to the appropriate <spanstyle="font-family:monospace">ejabberd</span> node or
process. If it does not exists in either tables, then it sent to the S2S
manager.</p>
<!--TOC subsection id="sec6" Local Router-->
<h3id="sec6"class="subsection">3.2  Local Router</h3><!--SEC END --><p>This module routes packets which have a destination domain equal to this server
name. If destination JID has a non-empty user part, then it routed to the
session manager, else it is processed depending on it’s content.</p>
<!--TOC subsection id="sec7" Session Manager-->
<h3id="sec7"class="subsection">3.3  Session Manager</h3><!--SEC END --><p>This module routes packets to local users. It searches for what user resource
packet must be sent via presence table. If this resource is connected to
this node, it is routed to C2S process, if it connected via another node, then
the packet is sent to session manager on that node.</p>
<!--TOC subsection id="sec8" S2S Manager-->
<h3id="sec8"class="subsection">3.4  S2S Manager</h3><!--SEC END --><p>This module routes packets to other XMPP servers. First, it checks if an
open S2S connection from the domain of the packet source to the domain of
packet destination already exists. If it is open on another node, then it
routes the packet to S2S manager on that node, if it is open on this node, then
it is routed to the process that serves this connection, and if a connection
does not exist, then it is opened and registered.</p>
<!--TOC section id="sec9" Authentication-->
<h2id="sec9"class="section">4  Authentication</h2><!--SEC END -->
<!--TOC subsubsection id="sec10" External-->
<h4id="sec10"class="subsubsection">4.0.1  External</h4><!--SEC END --><p>
<aid="externalauth"></a>
</p><p>The external authentication script follows
<ahref="http://www.erlang.org/doc/tutorial/c_portdriver.html">the erlang port driver API</a>.</p><p>That script is supposed to do theses actions, in an infinite loop:
</p><ulclass="itemize"><liclass="li-itemize">
read from stdin: AABBBBBBBBB.....
<ulclass="itemize"><liclass="li-itemize">
A: 2 bytes of length data (a short in network byte order)
</li><liclass="li-itemize">B: a string of length found in A that contains operation in plain text
operation are as follows:
<ulclass="itemize"><liclass="li-itemize">
auth:User:Server:Password (check if a username/password pair is correct)
</li><liclass="li-itemize">isuser:User:Server (check if it’s a valid user)
</pre>Returns string representation of XML stanza <spanstyle="font-family:monospace">El</span>.</dd><dtclass="dt-description"></dt><ddclass="dd-description"><code>crypt(S) -> string()</code>
<preclass="verbatim">S = string()
</pre>Returns string which correspond to <spanstyle="font-family:monospace">S</span> with encoded XML special
</pre><spanstyle="font-family:monospace">EList</span> is a list of all non-CDATA elements of ECList.</dd><dtclass="dt-description"></dt><ddclass="dd-description"><code>get_path_s(El, Path) -> Res</code>
<preclass="verbatim">El = XMLElement
Path = [PathItem]
PathItem = PathElem | PathAttr | PathCDATA
PathElem = {elem, Name}
PathAttr = {attr, Name}
PathCDATA = cdata
Name = string()
Res = string() | XMLElement
</pre>If <spanstyle="font-family:monospace">Path</span> is empty, then returns <spanstyle="font-family:monospace">El</span>. Else sequentially
consider elements of <spanstyle="font-family:monospace">Path</span>. Each element is one of:
<dlclass="description"><dtclass="dt-description">
</dt><ddclass="dd-description"><code>{elem, Name}</code><spanstyle="font-family:monospace">Name</span> is name of subelement of
<spanstyle="font-family:monospace">El</span>, if such element exists, then this element considered in
following steps, else returns empty string.
</dd><dtclass="dt-description"></dt><ddclass="dd-description"><code>{attr, Name}</code> If <spanstyle="font-family:monospace">El</span> have attribute <spanstyle="font-family:monospace">Name</span>, then
returns value of this attribute, else returns empty string.
</dd><dtclass="dt-description"></dt><ddclass="dd-description"><code>cdata</code> Returns CDATA of <spanstyle="font-family:monospace">El</span>.
</div><blockquoteclass="quotation"><spanstyle="color:#921700"><spanstyle="font-style:italic">I can thoroughly recommend ejabberd for ease of setup –
Kevin Smith, Current maintainer of the Psi project</span></span></blockquote><p>Introduction
<aid="intro"></a></p><blockquoteclass="quotation"><spanstyle="color:#921700"><spanstyle="font-style:italic">I just tried out ejabberd and was impressed both by ejabberd itself and the language it is written in, Erlang. —
Joeri</span></span></blockquote><p><spanstyle="font-family:monospace">ejabberd</span> is a <spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">free and open source</span></span></span> instant messaging server written in <ahref="http://www.erlang.org/">Erlang/OTP</a>.</p><p><spanstyle="font-family:monospace">ejabberd</span> is <spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">cross-platform</span></span></span>, distributed, fault-tolerant, and based on open standards to achieve real-time communication.</p><p><spanstyle="font-family:monospace">ejabberd</span> is designed to be a <spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">rock-solid and feature rich</span></span></span> XMPP server.</p><p><spanstyle="font-family:monospace">ejabberd</span> is suitable for small deployments, whether they need to be <spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">scalable</span></span></span> or not, as well as extremely big deployments.</p>
<!--TOC section id="sec1" Key Features-->
<h2id="sec1"class="section">Key Features</h2><!--SEC END --><p>
<aid="keyfeatures"></a>
</p><blockquoteclass="quotation"><spanstyle="color:#921700"><spanstyle="font-style:italic">Erlang seems to be tailor-made for writing stable, robust servers. —
Peter Saint-André, Executive Director of the Jabber Software Foundation</span></span></blockquote><p><spanstyle="font-family:monospace">ejabberd</span> is:
</p><ulclass="itemize"><liclass="li-itemize">
<spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Cross-platform:</span></span></span><spanstyle="font-family:monospace">ejabberd</span> runs under Microsoft Windows and Unix derived systems such as Linux, FreeBSD and NetBSD.</li><liclass="li-itemize"><spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Distributed:</span></span></span> You can run <spanstyle="font-family:monospace">ejabberd</span> on a cluster of machines and all of them will serve the same Jabber domain(s). When you need more capacity you can simply add a new cheap node to your cluster. Accordingly, you do not need to buy an expensive high-end machine to support tens of thousands concurrent users.</li><liclass="li-itemize"><spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Fault-tolerant:</span></span></span> You can deploy an <spanstyle="font-family:monospace">ejabberd</span> cluster so that all the information required for a properly working service will be replicated permanently on all nodes. This means that if one of the nodes crashes, the others will continue working without disruption. In addition, nodes also can be added or replaced ‘on the fly’.</li><liclass="li-itemize"><spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Administrator Friendly:</span></span></span><spanstyle="font-family:monospace">ejabberd</span> is built on top of the Open Source Erlang. As a result you do not need to install an external database, an external web server, amongst others because everything is already included, and ready to run out of the box. Other administrator benefits include:
<ulclass="itemize"><liclass="li-itemize">
Comprehensive documentation.
</li><liclass="li-itemize">Straightforward installers for Linux, Mac OS X, and Windows. </li><liclass="li-itemize">Web Administration.
</li><liclass="li-itemize">Shared Roster Groups.
</li><liclass="li-itemize">Command line administration tool. </li><liclass="li-itemize">Can integrate with existing authentication mechanisms.
</li><liclass="li-itemize">Capability to send announce messages.
</li></ul></li><liclass="li-itemize"><spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Internationalized:</span></span></span><spanstyle="font-family:monospace">ejabberd</span> leads in internationalization. Hence it is very well suited in a globalized world. Related features are:
<ulclass="itemize"><liclass="li-itemize">
Translated to 25 languages. </li><liclass="li-itemize">Support for <ahref="http://www.ietf.org/rfc/rfc3490.txt">IDNA</a>.
</li></ul></li><liclass="li-itemize"><spanstyle="font-weight:bold"><spanstyle="font-size:large"><spanstyle="color:#001376">Open Standards:</span></span></span><spanstyle="font-family:monospace">ejabberd</span> is the first Open Source Jabber server claiming to fully comply to the XMPP standard.
<h2id="sec2"class="section">Additional Features</h2><!--SEC END --><p>
<aid="addfeatures"></a>
</p><blockquoteclass="quotation"><spanstyle="color:#921700"><spanstyle="font-style:italic">ejabberd is making inroads to solving the "buggy incomplete server" problem —
Justin Karneges, Founder of the Psi and the Delta projects</span></span></blockquote><p>Moreover, <spanstyle="font-family:monospace">ejabberd</span> comes with a wide range of other state-of-the-art features:
</p><ulclass="itemize"><liclass="li-itemize">
Modular
<ulclass="itemize"><liclass="li-itemize">
Load only the modules you want.
</li><liclass="li-itemize">Extend <spanstyle="font-family:monospace">ejabberd</span> with your own custom modules.
</li></ul>
</li><liclass="li-itemize">Security
<ulclass="itemize"><liclass="li-itemize">
SASL and STARTTLS for c2s and s2s connections.
</li><liclass="li-itemize">STARTTLS and Dialback s2s connections.
</li><liclass="li-itemize">Web Admin accessible via HTTPS secure access.
</li><liclass="li-itemize">ODBC data storage support.
</li><liclass="li-itemize">Microsoft SQL Server support. </li><liclass="li-itemize">Riak NoSQL database support.
</li></ul>
</li><liclass="li-itemize">Authentication
<ulclass="itemize"><liclass="li-itemize">
Internal Authentication.
</li><liclass="li-itemize">PAM, LDAP, ODBC and Riak. </li><liclass="li-itemize">External Authentication script.
</li></ul>
</li><liclass="li-itemize">Others
<ulclass="itemize"><liclass="li-itemize">
Support for virtual hosting.
</li><liclass="li-itemize">Compressing XML streams with Stream Compression (<ahref="http://www.xmpp.org/extensions/xep-0138.html">XEP-0138</a>).
</li><liclass="li-itemize">Statistics via Statistics Gathering (<ahref="http://www.xmpp.org/extensions/xep-0039.html">XEP-0039</a>).
</li><liclass="li-itemize">IPv6 support both for c2s and s2s connections.
</li><liclass="li-itemize"><ahref="http://www.xmpp.org/extensions/xep-0045.html">Multi-User Chat</a> module with support for clustering and HTML logging. </li><liclass="li-itemize">Users Directory based on users vCards.
</li><liclass="li-itemize"><ahref="http://www.xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a> component with support for <ahref="http://www.xmpp.org/extensions/xep-0163.html">Personal Eventing via Pubsub</a>.
</li><liclass="li-itemize">Support for web clients: <ahref="http://www.xmpp.org/extensions/xep-0025.html">HTTP Polling</a> and <ahref="http://www.xmpp.org/extensions/xep-0206.html">HTTP Binding (BOSH)</a> services.
</li><liclass="li-itemize">IRC transport.
</li><liclass="li-itemize">SIP support.
</li><liclass="li-itemize">Component support: interface with networks such as AIM, ICQ and MSN installing special tranports.
</li></ul>
</li></ul><!--CUT END -->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<hrstyle="height:2"><blockquoteclass="quote"><em>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
%% TODO: improve the feature sheet with a nice table to highlight new features.
\quoting{I just tried out ejabberd and was impressed both by ejabberd itself and the language it is written in, Erlang. ---
Joeri}
%ejabberd is a free and open source instant messaging server written in Erlang. ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication (Jabber/XMPP).
\ejabberd{} is a \marking{free and open source} instant messaging server written in \footahref{http://www.erlang.org/}{Erlang/OTP}.
\ejabberd{} is \marking{cross-platform}, distributed, fault-tolerant, and based on open standards to achieve real-time communication.
\ejabberd{} is designed to be a \marking{rock-solid and feature rich} XMPP server.
\ejabberd{} is suitable for small deployments, whether they need to be \marking{scalable} or not, as well as extremely big deployments.
%\subsection{Layout with example deployment (title needs a better name)}
%\label{layout}
%In this section there will be a graphical overview like these:\\
%A page full with names of Jabber client that are known to work with ejabberd. \begin{tiny}tiny font\end{tiny}
%\subsection{Try It Today}
%\label{trytoday}
%(Not sure if I will include/finish this section for the next version.)
%\begin{itemize}
%\item Erlang REPOS
%\item Packages in distributions
%\item Windows binary
%\item source tar.gz
%\item Migration from Jabberd14 (and so also Jabberd2 because you can migrate from version 2 back to 14) and Jabber Inc. XCP possible.
%\end{itemize}
\newpage
\section{Key Features}
\label{keyfeatures}
\ind{features!key features}
\quoting{Erlang seems to be tailor-made for writing stable, robust servers. ---
Peter Saint-Andr\'e, Executive Director of the Jabber Software Foundation}
\ejabberd{} is:
\begin{itemize}
\item\marking{Cross-platform:}\ejabberd{} runs under Microsoft Windows and Unix derived systems such as Linux, FreeBSD and NetBSD.
\item\marking{Distributed:} You can run \ejabberd{} on a cluster of machines and all of them will serve the same \Jabber{} domain(s). When you need more capacity you can simply add a new cheap node to your cluster. Accordingly, you do not need to buy an expensive high-end machine to support tens of thousands concurrent users.
\item\marking{Fault-tolerant:} You can deploy an \ejabberd{} cluster so that all the information required for a properly working service will be replicated permanently on all nodes. This means that if one of the nodes crashes, the others will continue working without disruption. In addition, nodes also can be added or replaced `on the fly'.
\item\marking{Administrator Friendly:}\ejabberd{} is built on top of the Open Source Erlang. As a result you do not need to install an external database, an external web server, amongst others because everything is already included, and ready to run out of the box. Other administrator benefits include:
\begin{itemize}
\item Comprehensive documentation.
\item Straightforward installers for Linux, Mac OS X, and Windows. %%\improved{}
\item Web Administration.
\item Shared Roster Groups.
\item Command line administration tool. %%\improved{}
\item Can integrate with existing authentication mechanisms.
\item Capability to send announce messages.
\end{itemize}
\item\marking{Internationalized:}\ejabberd{} leads in internationalization. Hence it is very well suited in a globalized world. Related features are:
\begin{itemize}
\item Translated to 25 languages. %%\improved{}
\item Support for \footahref{http://www.ietf.org/rfc/rfc3490.txt}{IDNA}.
\end{itemize}
\item\marking{Open Standards:}\ejabberd{} is the first Open Source Jabber server claiming to fully comply to the XMPP standard.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.