Protocols/MSNP/Switchboard/Authentication: Difference between revisions
m (1 revision imported) |
Animadoria (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
{{Protocols/MSNP}} | |||
There are two ways to connect to a switchboard: you can either request a new switchboard session or be invited to an existing one. Both of these events take place on the notification server. When connecting to the switchboard, a client will need to handle the creation of a session (XFR) and being invited (RNG) somewhat differently. | There are two ways to connect to a switchboard: you can either request a new switchboard session or be invited to an existing one. Both of these events take place on the notification server. When connecting to the switchboard, a client will need to handle the creation of a session (XFR) and being invited (RNG) somewhat differently. |
Latest revision as of 13:55, 15 May 2022
MSNP Protocol |
Introduction • Terms • Clients |
Reference |
Error List • Commands • Relying Party Suite • Spotlife |
Services |
XMPP • HTTP Gateway • Tabs • Activities |
Documentation |
Development Tools • MSNP Grid |
Polygamy • URLs used by MSN |
Documents |
Protocol Versions |
Version 21 |
Version 18 |
Version 16 |
Version 15 |
Version 14 |
Version 13 |
Version 12 |
Version 11 |
Version 9 |
Version 8 |
Version 2 |
MSNC |
Introduction • P2P • Object Descriptor • Display Pictures • File Transfer |
Scenarios |
Microsoft Messenger for Mac |
MSNP on WebTV (MSNTV) |
There are two ways to connect to a switchboard: you can either request a new switchboard session or be invited to an existing one. Both of these events take place on the notification server. When connecting to the switchboard, a client will need to handle the creation of a session (XFR) and being invited (RNG) somewhat differently.
Requesting a Switchboard
To request a switchboard session, the client must send the XFR command to the NS with a TrID and a parameter of SB. The server will reply with another XFR with instructions on authenticating with the switchboard. Below is an example:
>>> XFR 15 SB\r\n <<< XFR 10 SB 207.46.108.37:1863 CKI 17262740.1050826919.32308\r\n
- The first parameter tells you that you are being transferred to a switchboard (this should always remain the same). Note that in the dispatch server, this parameter reads NS.
- The second parameter is the colon-delimited string for the address and port (has always been 1863) of the switchboard server.
- The third parameter specifies the type of authentication, which should always be CKI.
- The fourth parameter is an authentication string that the client will need to send when connecting to the switchboard to prove its identity.
However, if you have not set your initial status, or you are set to HDN, you may not transfer to a switchboard. Instead of receiving an XFR in response to your XFR, you will receive error 913.
The client must now initiate a TCP connection to the given switchboard IP on the given port (without closing the NS connection). The connection details are as explained in the Connections page. The client can wait at least two minutes and still connect to the switchboard safely.
Once connected to the switchboard, the client must send the USR command. It must have a TrID, your account name as the first parameter, and the authentication string as the second parameter. This command must be sent within approximately one minute or else the switchboard will close the connection.
If successful, the server will respond with a USR with the same TrID, OK as the first parameter, your account name as the second parameter, and your display name as the third parameter.
- If of either (or both) the account name or the authentication string were incorrect, the server will send error 911 and close the connection.
- If the format was wrong, the server will immediately close the connection with no error.
- If you try to authenticate with the correct information with the wrong switchboard server (different IP), you will be disconnected with no error.
- If you have already logged into the switchboard server with the authentication information, and try to log in again with the same information, you will receive error 911 and be disconnected. Note that you can still connect to multiple switchboards simultaneously, but you must send multiple XFRs and use each one separately.
<o> Client Connects to 207.46.108.37 1863 (Switchboard) >>> USR 1 example@passport.com 17262740.1050826919.32308\r\n <<< USR 1 OK example@passport.com Example%20Name\r\n <o> Continue SB Session . . .
Getting Invited to a Switchboard
When a principal invites you to a switchboard session, you will receive an RNG command over the notification server. The official client will automatically connect to a switchboard session and won't open a chat window until a plaintext message is sent, but third party clients may choose to behave differently.
The RNG command is an asynchronous command and five parameters:
- The first parameter is the session ID of the new switchboard session. Every switchboard session has a unique ID, and each principal invited will use the same session ID. You will need this for authenticating with the switchboard.
- The second parameter is the colon-delimited string for the address and port (has always been 1863) of the switchboard.
- The third parameter specifies the type of authentication, which should always be CKI.
- The fourth parameter is an authentication string that you will need when authenticating with the switchboard.
- The fifth and sixth parameters are respectively the account name and the URL-encoded display name of the principal that invited you to the switchboard session.
<<< RNG 11752013 207.46.108.38:1863 CKI 849102291.520491113 example@passport.com Example%20Name\r\n
The client does not respond to this command. Instead, it opens a new connection to the IP and port given in the second parameter.