SASL_CLIENT_START(3)

✨ SASL_CLIENT_START(3) ✨

okay bestie, gather round, because we're cracking open sasl_client_start from the Cyrus SASL manual, section 3 (library functions, iykyk). this is the one that kicks off the whole authentication glow-up. let's get into it 💅

---

🌸 NAME 🌸

sasl_client_start — Cyrus SASL documentation

(that's it, that's the name, short and iconic 👑

---

🦋 SYNOPSIS 🦋

#include <sasl/sasl.h>

int sasl_client_start(sasl_conn_t * conn,
        const char * mechlist,
        sasl_interact_t ** prompt_need,
        const char ** clientout,
        unsigned * clientoutlen,
        const char ** mech);

---

💖 DESCRIPTION 💖

so, same signature again but with ✨spacing✨ because the original manpage said so, and we respect the original:

int sasl_client_start(sasl_conn_t * conn,

const char * mechlist,

sasl_interact_t ** prompt_need,

const char ** clientout,

unsigned * clientoutlen,

const char ** mech);

sasl_client_start() does two big things: it picks a mechanism for authentication, and it starts the authentication session. main character energy fr fr.

the mechlist is the list of mechanisms the client might like to use. and listen — the mechanisms in that list are not necessarily supported by the client, and they're not even necessarily valid. so don't come for her if some of them are fake. SASL decides which of these to actually use based on the security preferences you specified earlier. typically, mechlist is a list of mechanisms the server supports, acquired from a capability request. 🎀

if SASL_INTERACT comes back at you, that means the library needs some values filled in before it can keep going. the prompt_need structure gets filled in with the requests. your app should fulfill those requests and then call sasl_client_start again with identical parameters — and heads up, the prompt_need parameter will be the same pointer as before, just now filled in by the application. no cap.

🌈 Parameters 🌈

• conn — is the SASL connection context. your lil connection bby.
• mechlist — is a list of mechanisms the server has available. Punctuation is ignored. so like, commas and stuff? she doesn't care, she's above it.
• prompt_need — is filled in with a list of prompts needed to continue (if necessary).
• clientout — is created. it's 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) that's necessary needs to be done by the client. 💀
  • if the protocol lacks client-send-first capability, then set clientout to NULL.
  • if there is no initial client-send, then *clientout will be set to NULL on return.
• clientoutlen — length of clientout.
• mech — contains the name of the chosen SASL mechanism (on success).

---

🔥 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. (she's not done yet, she's just getting started ✨)

other return codes indicate errors and should either be handled, or the authentication session should be quit. like, genuinely, no shade, just close the door and walk away 🚪💀

---

👑 SEE ALSO 👑

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

(the whole friend group 🫶 go read them all, they're all serving)

---

🧚 AUTHOR 🧚

The Cyrus Team

---

🎀 COPYRIGHT 🎀

1993-2016, The Cyrus Team

---

and that's the tea, bestie ☕ this page is straight outta Cyrus SASL version 2.1.28, dated February 18, 2022 — so if you're reading this in the group chat, that's the version and date it was born. periodt. 💖✨