SASL_CLIENT_STEP(3)

💅 SASL_CLIENT_STEP(3) — Cyrus SASL, bestie edition 🎀

okay so you're deep in the Cyrus SASL docs (that's the manual name, iykyk) and you found the one that does the ✨negotiation step✨. pull up a chair, we're doing this together.

---

✨ NAME ✨

sasl_client_step — Cyrus SASL documentation, but make it a group chat 🫶

---

🌸 SYNOPSIS 🌸

#include <sasl/sasl.h>

int sasl_client_step(sasl_conn_t *conn,
               const char *serverin,
               unsigned serverinlen,
               sasl_interact_t ** prompt_need,
               const char ** clientout,
               unsigned * clientoutlen);

---

💖 DESCRIPTION 💖

int sasl_client_step(sasl_conn_t *conn,

const char *serverin,

unsigned serverinlen,

sasl_interact_t ** prompt_need,

const char ** clientout,

unsigned * clientoutlen);

sasl_client_step() performs a step in the authentication negotiation. literally one single step, like one foot in front of the other 🚶♀️

it returns SASL_OK if the whole negotiation is successful and SASL_CONTINUE if this step is ok but at least one more step is needed. so SASL_CONTINUE is giving "not yet bestie, keep going" energy.

🚨 IMPORTANT REALITY CHECK: a client should not assume an authentication negotiation is successful just because the server signaled success via protocol. i.e. if the server said “. OK Authentication succeeded” in IMAP, sasl_client_step should still be called one more time with a serverinlen of zero. yes fr fr, one more time. don't skip it, don't be that girl 💀

If SASL_INTERACT is returned, the library needs some values to be filled in before it can proceed. the prompt_need structure will be filled in with requests. the application should fulfill these requests and call sasl_client_start again with identical parameters (the prompt_need parameter will be the same pointer as before but filled in by the application). same pointer, new contents, no cap 👑

🦋 Parameters 🦋

• conn – is the SASL connection context. your little context holder, the main character of the connection 🫶
• serverin – is the data given by the server (decoded if the protocol encodes requests sent over the wire)
• serverinlen – is the length of serverin
• clientout – is created. It is the initial client response to send to the server. It is the job of the client to send it over the network to the server. any protocol specific encoding (such as base64 encoding) necessary needs to be done by the client. so like, the library hands you the goods, you do the wrapping and the mailing 💌
• clientoutlen – length of clientout.

---

🔥 RETURN VALUE 🔥

SASL callback functions should return SASL return codes. See sasl.h for a complete list.

• SASL_CONTINUE indicates success and that there are more steps needed in the authentication. (success but keep it moving ✨)
• SASL_OK indicates that the authentication is complete. (we ate, periodt 👑)

other return codes indicate errors and should either be handled or the authentication session should be quit. like, genuinely quit. don't just leave it hanging there 😭

---

🌈 SEE ALSO 🌈

RFC 4422,:saslman:sasl(3), sasl_callbacks(3), sasl_client_init(3), sasl_client_new(3), sasl_client_start(3), sasl_errors(3)

the whole friend group, go say hi 💜

---

🎀 AUTHOR 🎀

The Cyrus Team 👑

💜 COPYRIGHT 💜

1993-2016, The Cyrus Team

---

and that's the tea, bestie 🍓 this was Cyrus SASL 2.1.28, dated February 18, 2022 — mwah, iconic, no notes 💅✨🦋