Difference between revisions of "Client Test Cases"

From XMPP WIKI
Jump to navigation Jump to search
Line 29: Line 29:
# MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
# MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
# Impersonation via XEP-0297 Stanza Forwarding:
# Impersonation via XEP-0297 Stanza Forwarding:
    Similar to the MAM impersonation but with a top-level <forward> element.
Similar to the MAM impersonation but with a top-level <forward> element.
    Clients are supposed to clearly indicate that a message has been forwarded.
Clients are supposed to clearly indicate that a message has been forwarded.
    Misbehaving clients might instead show the forwarded message as if it came from that person.
Misbehaving clients might instead show the forwarded message as if it came from that person.
    There's also zero guarantee that a forwarded message is not in fact a forgery.
There's also zero guarantee that a forwarded message is not in fact a forgery.


= Multi User Chats =
= Multi User Chats =

Revision as of 14:13, 13 September 2019

This is a list of different test cases that client developers should apply to their code base.


Tool Suite

TODO: create and document an automated tool suite.

An ideal tool suite would be one of (or all of):

  • A hosted component with well-defined JIDs exhibiting the test case behavior
  • An XMPP component that can be self-hosted
  • A set of bot scripts / tools that can connect to a given (set of) account(s)

Message Errors

A client should properly support the following cases:

  1. A message is rejected by the other side - display error on message, show text message describing the failure in the details
  2. A message is accepted by the other side (you receive a Receipt) - display normally or with an additional checkmark
  3. A message is accepted (Receipt), then bounced (you receive an error) - the error is probably from a stale session and should be ignored - display checkmark
  4. A message is bounced, then accepted - first display error, then checkmark

There is a hosted version of test 1. at xmpp:reject@yax.im

Impersonation attacks

  1. Roster push impersonation CVE-2015-8688
  2. Carbon sender impersonation CVE-2017-5589
  3. MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
  4. Impersonation via XEP-0297 Stanza Forwarding:

Similar to the MAM impersonation but with a top-level <forward> element. Clients are supposed to clearly indicate that a message has been forwarded. Misbehaving clients might instead show the forwarded message as if it came from that person. There's also zero guarantee that a forwarded message is not in fact a forgery.

Multi User Chats

Joining

  1. A join is not responded to at all by the MUC
  2. A join is responded to with an error presence
  3. A join is responded with a captcha challenge message
  4. After sending the captcha challenge response a MUC responds with a "not-authorized" error presence (which does *not* mean in this case the muc is password protected)
  5. Captcha messages may be archived (MAM) by the server, a client should ignore them
  6. The join response does not contain a subject
  7. The join response does not contain a self-presence
  8. The join response neither contains a subject nor a self-presence

Staying inside

  1. The client gets kicked by the MUC, with or without a message
  2. The client gets banned by the MUC, with or without a message
  3. The MUC join completes, but the occupant is then silently removed, all subsequent messages get rejected (see XEP-0410)

MUC-PMs

TODO

Affiliation

  1. The client gets muted by the MUC, with or without a message

Other

  1. Another occupant sends an invalid presence to the room (I'm looking at you, old Gajim)

HTTP File Upload

A testing component could reject the file slot request IQ with different errors based on the requested file name / file size. A client developer would have a set of according files to trigger different conditions.

Jingle

TODO: all kinds of handshake failures

MAM

TODO: incomplete archive, incoherent IDs, duplicates