Difference between revisions of "Client Test Cases"
Jump to navigation
Jump to search
(Added bookmarks) |
|||
Line 88: | Line 88: | ||
# Client attempts to fetch MAM with a MAM-ID that is unknown to the server (because it expired) | # Client attempts to fetch MAM with a MAM-ID that is unknown to the server (because it expired) | ||
= Bookmarks = | |||
# bookmark request isn't ever responded to | |||
# bookmarks mix "0" and "no" as boolean representations | |||
# the bookmark response contains unknown elements | |||
# does the client join auto join bookmarks? | |||
# does the client honor bookmark nicknames? Will it use the default nickname where none is set? | |||
# does the client honor bookmark names? | |||
# will the client break / change any of those when writing bookmarks? | |||
[[Category:Interop]] | [[Category:Interop]] |
Latest revision as of 16:38, 22 October 2020
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:
- A message is rejected by the other side - display error on message, show text message describing the failure in the details
- A message is accepted by the other side (you receive a Receipt) - display normally or with an additional checkmark
- 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
- 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
- Roster push impersonation CVE-2015-8688
- Carbon sender impersonation CVE-2017-5589
- MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
- 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.
Session Management
- A client performs all session initation operations the correct order
- A client properly accepts a different resource than requested during binding, and responds to IQs sent to it
- Stream Management (XEP-0198)
- A client resumes a session with the same session-id if disconnected without closing the XML stream
- A client submits the correct number of stanzas on resume, after it was fed with some messages, IQs, and other (non-stanza) stream elements
- A client aborts the resume if the server requests stanzas that already were ACKed before the connection loss (<resumed h> with a value smaller than in the last <a/> element)
- A client aborts the resume if the server less stanzas than the client (<resumed h> with a value significantly larger than what the client sent)
Roster Management
- When a subscription request was approved / denied from a different device, update the roster view, remove pending popups
Multi User Chats
Joining
- A join is not responded to at all by the MUC
- A join is responded to with an error presence
- A join is responded with a captcha challenge message
- 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)
- Captcha messages may be archived (MAM) by the server, a client should ignore them
- The join response does not contain a subject
- The join response does not contain a self-presence
- The join response neither contains a subject nor a self-presence
Staying inside
- The client gets kicked by the MUC, with or without a message
- The client gets banned by the MUC, with or without a message
- The MUC join completes, but the occupant is then silently removed, all subsequent messages get rejected (see XEP-0410)
MUC-PMs
TODO
Affiliation
- The client gets muted by the MUC, with or without a message
Other
- 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
- Client attempts to fetch MAM with a MAM-ID that is unknown to the server (because it expired)
Bookmarks
- bookmark request isn't ever responded to
- bookmarks mix "0" and "no" as boolean representations
- the bookmark response contains unknown elements
- does the client join auto join bookmarks?
- does the client honor bookmark nicknames? Will it use the default nickname where none is set?
- does the client honor bookmark names?
- will the client break / change any of those when writing bookmarks?