Why cyrsasl_scram mechanism is not allowing base64 GUID?

Question

I am writing a chat communication app. If the user's unique id is given in Base 64 GUID format, it is throwing bad_username error.

In this file: https://pow.gs/mirror/ejabberd/-/blob/fd8e07af4789be362a61755ea47f216baeb64989/src/cyrsasl_scram.erl, there is a method to remove the == from username:

unescape_username(<<"">>) -> <<"">>;
unescape_username(EscapedUsername) ->
    Pos = str:str(EscapedUsername, <<"=">>),
    if Pos == 0 -> EscapedUsername;
       true ->
       Start = str:substr(EscapedUsername, 1, Pos - 1),
       End = str:substr(EscapedUsername, Pos),
       EndLen = byte_size(End),
       if EndLen < 3 -> error;
          true ->
          case str:substr(End, 1, 3) of
            <<"=2C">> ->
            <<Start/binary, ",",
              (unescape_username(str:substr(End, 4)))/binary>>;
            <<"=3D">> ->
            <<Start/binary, "=",
              (unescape_username(str:substr(End, 4)))/binary>>;
            _Else -> error
          end
       end
    end.

I don't know why this has been written. If I remove this particular code, the connection is working fine. Please let me know why it is restricted.

Answer 1

If the users' unique id is given in Base 64 GUID format, it is throwing bad_username error.

Right:

 call xmpp_sasl_scram:unescape_username(<<"user1">>)
 returned from xmpp_sasl_scram:unescape_username/1 -> <<"user1">>

 call xmpp_sasl_scram:unescape_username(<<"user3==ABC">>)
 returned from xmpp_sasl_scram:unescape_username/1 -> error

 call xmpp_sasl_scram:unescape_username(<<"user4=DEF">>)
 returned from xmpp_sasl_scram:unescape_username/1 -> error

 call xmpp_sasl_scram:unescape_username(<<"user5=">>)
 returned from xmpp_sasl_scram:unescape_username/1 -> error

I don't know why this has been written. If I remove this particular code, the connection is working fine. Please let me know why it is restricted.

I don't know, either. But that code exists since nine years ago: https://github.com/processone/ejabberd/commit/e80b92b48148505b44c6a378db36badfe60fce79#diff-5c51943c1268ffe26fe3b041b20675c6R136

Whatever reason there is for it, it's obviously a good reason.