shv login example

Login example

Login with plain password

Client connects to server, than it calls the method hello

<1:1,8:1,10:"hello">i{}

server replies with random nonce

<1:1,8:1>i{2:{"nonce":"65673561"}}

client replies with login call, note that the nonce sent by server is not used here, because PLAIN password is used

<1:1,8:2,10:"login">i{1:{"login":{"password":"good password","type":"PLAIN","user":"tester"},"options":{"idleWatchDogTimeOut":180}}}

server replies with clientId in case of success

<1:1,8:2>i{2:{"clientId":2}}

when anything is wrong (password or user-name), then server replies with error

<1:1,8:16>i{3:i{1:8,2:"Invalid authentication for user: tester reason: Invalid password. at: 127.0.0.1:33920"}}

Wireshark files with captured communication:

• chainpack-plain-password-login.pcapng
• cpon-plain-password-login.pcapng

Login with SHA1 password

This is the preferred authentication method because a password is sent only as a digest randomized by nonce even through an unsafe data channel. Here the nonce sent by server comes to play, login password is generated by client as password = HEX(SHA1(nonce + HEX(SHA1(password))))

Example:

• password: good password
• HEX(SHA1(password)): f3248c2e2fbf00be324a79c7ea317e9923b6b560
• nonce + HEX(SHA1(password)): 1429255113f3248c2e2fbf00be324a79c7ea317e9923b6b560
• HEX(SHA1(nonce + HEX(SHA1(password)))): 0b72f013e8b65a6a57386f0ec3b85e2517b500bc

==> <1:1,8:17,10:"hello">i{}
<== <1:1,8:17>i{2:{"nonce":"1429255113"}}
==> <1:1,8:18,10:"login">i{1:{"login":{"password":"0b72f013e8b65a6a57386f0ec3b85e2517b500bc","type":"SHA1","user":"tester"},"options":{"idleWatchDogTimeOut":180}}}
<== <1:1,8:18>i{2:{"clientId":4}}

Wireshark files with captured communication:

• chainpack-sha1-password-login.pcapng
• cpon-sha1-password-login.pcapng

Notes

• RPC calls on server can be coded by Cpon (text) or ChainPack (binary) protocol
• Every message has following form | length | format | data | where:
  • length is length of data + 1
    • length is coded as ChainPack UInt data, see ChainPack-RPC#uint
  • format is 1 byte specifying the data format used
    • 1 for binary ChainPack, which is the preferred one
    • 2 for text Cpon, which is utilized mainly for debugging purposes
• Every message consist of <meta-data-part> and i{data-part}, see ChainPack-RPC#rpc for example:
  • <1:1,8:17,10:"hello">i{} is RPC request since meta-data contains method key 10:
    • meta part
      • 1:1 - type: ChainPack RPC
      • 8:17 - requestId: 17
      • 10:"hello" - method: hello
    • data part
      • empty - no parameter
  • <1:1,8:17>i{2:{"nonce":"1429255113"}} is RPC response since meta-data does not contain method key 10:
    • meta part
      • 1:1 - MetaTypeId: ChainPackRpcMessage https://github.com/silicon-heaven/libshv/blob/f54e19d9e922d0c0d161b96008c3607746326d04/libshvchainpack/src/chainpack/metatypes.h#L90
      • 8:17 - requestId: 17, actualy response to request with id == 17
    • data part
      • i{2:{"nonce":"1429255113"}} - RPC call result == {"nonce":"1429255113"}