DJabberd
view release on metacpan or search on metacpan
and we may still want to process/deliver.
-- Jingle/Asterisk stuff:
This Jabber client supports Jingle:
http://www.kismith.co.uk/wordpress/index.php/2005/12/16/i-say-i-say-i-say-did-you-hear-the-one-about/
http://psi-im.org/wiki/Jingle_branch
So think we could do the Jingle stuff Jabber-server-side and get the Psi
client connecting to Asterisk over SIP or something?
-- <not-authorized/> -- the sender must provide proper credentials
before being allowed to perform the action, or has provided
improper credentials; the associated error type SHOULD be "auth". no error currently gets sent on non AUTH
-- need to write some tests for components
-- need a better API for components so they aren't so ugly. maybe just a nice subclass?
-- make Component subclass that implements JEP-0114
-- privsep for security and scalability
-- network read eval should do something different on xml versus perl errors
doc/rfc3920-notes.txt view on Meta::CPAN
This series of challenge/response pairs continues until one of three
things happens:
1. The initiating entity aborts the handshake by sending an <abort/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity. Upon receiving an <abort/>
element, the receiving entity SHOULD allow a configurable but
reasonable number of retries (at least 2), after which it MUST
terminate the TCP connection; this enables the initiating entity
(e.g., an end-user client) to tolerate incorrectly-provided
credentials (e.g., a mistyped password) without being forced to
reconnect.
Saint-Andre, Ed. Standards Track [Page 29]
RFC 3920 XMPP Core October 2004
2. The receiving entity reports failure of the handshake by sending
a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity (the particular cause of failure SHOULD be communicated in
an appropriate child element of the <failure/> element as defined
under SASL Errors (Section 6.4)). If the failure case occurs,
the receiving entity SHOULD allow a configurable but reasonable
number of retries (at least 2), after which it MUST terminate the
TCP connection; this enables the initiating entity (e.g., an
end-user client) to tolerate incorrectly-provided credentials
(e.g., a mistyped password) without being forced to reconnect.
3. The receiving entity reports success of the handshake by sending
a <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY contain XML character data (in SASL
terminology, "additional data with success") if required by the
chosen SASL mechanism. Upon receiving the <success/> element,
the initiating entity MUST initiate a new stream by sending an
opening XML stream header to the receiving entity (it is not
doc/rfc3920-notes.txt view on Meta::CPAN
RFC 3920 XMPP Core October 2004
o <mechanism-too-weak/> -- The mechanism requested by the initiating
entity is weaker than server policy permits for that initiating
entity; sent in reply to a <response/> element or an <auth/>
element with initial response data.
o <not-authorized/> -- The authentication failed because the
initiating entity did not provide valid credentials (this includes
but is not limited to the case of an unknown username); sent in
reply to a <response/> element or an <auth/> element with initial
response data.
o <temporary-auth-failure/> -- The authentication failed because of
a temporary error condition within the receiving entity; sent in
reply to an <auth/> element or <response/> element.
6.5. Client-to-Server Example
doc/rfc3920-notes.txt view on Meta::CPAN
</stanza-kind>
The stanza-kind is one of message, presence, or iq.
The value of the <error/> element's 'type' attribute MUST be one of
the following:
o cancel -- do not retry (the error is unrecoverable)
o continue -- proceed (the condition was only a warning)
o modify -- retry after changing the data sent
o auth -- retry after providing credentials
o wait -- retry after waiting (the error is temporary)
The <error/> element:
o MUST contain a child element corresponding to one of the defined
stanza error conditions specified below; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
o MAY contain a <text/> child containing XML character data that
describes the error in more detail; this element MUST be qualified
doc/rfc3920-notes.txt view on Meta::CPAN
o <not-acceptable/> -- the recipient or server understands the
request but is refusing to process it because it does not meet
criteria defined by the recipient or server (e.g., a local policy
regarding acceptable words in messages); the associated error type
SHOULD be "modify".
o <not-allowed/> -- the recipient or server does not allow any
entity to perform the action; the associated error type SHOULD be
"cancel".
o <not-authorized/> -- the sender must provide proper credentials
before being allowed to perform the action, or has provided
improper credentials; the associated error type SHOULD be "auth".
o <payment-required/> -- the requesting entity is not authorized to
access the requested service because payment is required; the
associated error type SHOULD be "auth".
o <recipient-unavailable/> -- the intended recipient is temporarily
unavailable; the associated error type SHOULD be "wait" (note: an
application MUST NOT return this error if doing so would provide
information about the intended recipient's network availability to
an entity that is not authorized to know such information).
doc/rfc3920.txt view on Meta::CPAN
This series of challenge/response pairs continues until one of three
things happens:
1. The initiating entity aborts the handshake by sending an <abort/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity. Upon receiving an <abort/>
element, the receiving entity SHOULD allow a configurable but
reasonable number of retries (at least 2), after which it MUST
terminate the TCP connection; this enables the initiating entity
(e.g., an end-user client) to tolerate incorrectly-provided
credentials (e.g., a mistyped password) without being forced to
reconnect.
Saint-Andre, Ed. Standards Track [Page 29]
RFC 3920 XMPP Core October 2004
2. The receiving entity reports failure of the handshake by sending
a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity (the particular cause of failure SHOULD be communicated in
an appropriate child element of the <failure/> element as defined
under SASL Errors (Section 6.4)). If the failure case occurs,
the receiving entity SHOULD allow a configurable but reasonable
number of retries (at least 2), after which it MUST terminate the
TCP connection; this enables the initiating entity (e.g., an
end-user client) to tolerate incorrectly-provided credentials
(e.g., a mistyped password) without being forced to reconnect.
3. The receiving entity reports success of the handshake by sending
a <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY contain XML character data (in SASL
terminology, "additional data with success") if required by the
chosen SASL mechanism. Upon receiving the <success/> element,
the initiating entity MUST initiate a new stream by sending an
opening XML stream header to the receiving entity (it is not
doc/rfc3920.txt view on Meta::CPAN
RFC 3920 XMPP Core October 2004
o <mechanism-too-weak/> -- The mechanism requested by the initiating
entity is weaker than server policy permits for that initiating
entity; sent in reply to a <response/> element or an <auth/>
element with initial response data.
o <not-authorized/> -- The authentication failed because the
initiating entity did not provide valid credentials (this includes
but is not limited to the case of an unknown username); sent in
reply to a <response/> element or an <auth/> element with initial
response data.
o <temporary-auth-failure/> -- The authentication failed because of
a temporary error condition within the receiving entity; sent in
reply to an <auth/> element or <response/> element.
6.5. Client-to-Server Example
doc/rfc3920.txt view on Meta::CPAN
</stanza-kind>
The stanza-kind is one of message, presence, or iq.
The value of the <error/> element's 'type' attribute MUST be one of
the following:
o cancel -- do not retry (the error is unrecoverable)
o continue -- proceed (the condition was only a warning)
o modify -- retry after changing the data sent
o auth -- retry after providing credentials
o wait -- retry after waiting (the error is temporary)
The <error/> element:
o MUST contain a child element corresponding to one of the defined
stanza error conditions specified below; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
o MAY contain a <text/> child containing XML character data that
describes the error in more detail; this element MUST be qualified
doc/rfc3920.txt view on Meta::CPAN
o <not-acceptable/> -- the recipient or server understands the
request but is refusing to process it because it does not meet
criteria defined by the recipient or server (e.g., a local policy
regarding acceptable words in messages); the associated error type
SHOULD be "modify".
o <not-allowed/> -- the recipient or server does not allow any
entity to perform the action; the associated error type SHOULD be
"cancel".
o <not-authorized/> -- the sender must provide proper credentials
before being allowed to perform the action, or has provided
improper credentials; the associated error type SHOULD be "auth".
o <payment-required/> -- the requesting entity is not authorized to
access the requested service because payment is required; the
associated error type SHOULD be "auth".
o <recipient-unavailable/> -- the intended recipient is temporarily
unavailable; the associated error type SHOULD be "wait" (note: an
application MUST NOT return this error if doing so would provide
information about the intended recipient's network availability to
an entity that is not authorized to know such information).
lib/DJabberd/Stanza/SASL.pm view on Meta::CPAN
use warnings;
use base qw(DJabberd::Stanza);
use MIME::Base64 qw/encode_base64 decode_base64/;
sub on_recv_from_server { die "unimplemented" }
## TODO:
## check number of auth failures, force deconnection, bad for t time §7.3.5 policy-violation
## Provide hooks for Authen:: modules to return details about errors:
## - credentials-expired
## - account-disabled
## - invalid-authzid
## - temporary-auth-failure
## these hooks should probably additions to parameters taken by GetPassword, CheckClearText
## right now all these errors results in not-authorized being returned
sub on_recv_from_client {
my $self = shift;
return $self->handle_abort(@_)
( run in 0.243 second using v1.01-cache-2.11-cpan-4d50c553e7e )