<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 08.10.2020 05:42, Maxim Sobolev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAH7qZfvf0Q_8PZkSdUP5z8Be1Le81Dw7PyqOswZ7hQSYUSKykQ@mail.gmail.com">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">Hey folks,</div>
</div>
</div>
</div>
</blockquote>
Hi!<br>
<blockquote type="cite"
cite="mid:CAH7qZfvf0Q_8PZkSdUP5z8Be1Le81Dw7PyqOswZ7hQSYUSKykQ@mail.gmail.com">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div dir="ltr" data-smartmail="gmail_signature">
<div>The problem that I am hitting now is that we have
digest computation code duplicated in both modules (auth
vs. uac_auth), which of course is less than ideal from
many perspectives (2x code to test, code bloat, pain to
add more algorithms etc).</div>
</div>
</div>
</div>
</blockquote>
I agree that the uac / uac_auth code is a bit "all over the place"
and could use some re-org into a single "authentication-related"
module / directory / library.<br>
<blockquote type="cite"
cite="mid:CAH7qZfvf0Q_8PZkSdUP5z8Be1Le81Dw7PyqOswZ7hQSYUSKykQ@mail.gmail.com">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div dir="ltr" data-smartmail="gmail_signature">
<div><br>
</div>
<div>Now the question is what is the best way to deal with
it. Couple of options I have:</div>
<div><br>
</div>
<div>1. Make uas_auth use code from the auth module and add
it as a dependency. In general this seems to be the path
the project takes to solve this problem. The downside is
perhaps some small performance degradation as well some
overhead to define and maintain API. Also this method does
not work for smallish bits and pieces, too heavy-weight
for an API.</div>
</div>
</div>
</div>
</blockquote>
Classical module API approach - let's see if we can do better.<br>
<blockquote type="cite"
cite="mid:CAH7qZfvf0Q_8PZkSdUP5z8Be1Le81Dw7PyqOswZ7hQSYUSKykQ@mail.gmail.com">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div dir="ltr" data-smartmail="gmail_signature">
<div><br>
</div>
<div>2. Move code into the core. I think this is probably
the wrong direction, some application might not need auth
at all.
Just listing it for completeness sake. </div>
</div>
</div>
</div>
</blockquote>
I agree - no need to compile this code into the "opensips" binary if
the app only does IP authentication, for example.<br>
<blockquote type="cite"
cite="mid:CAH7qZfvf0Q_8PZkSdUP5z8Be1Le81Dw7PyqOswZ7hQSYUSKykQ@mail.gmail.com">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div dir="ltr" data-smartmail="gmail_signature">
<div>3. Move code into some kind of internal static library
(say "libospcore.a") and link both modules against that
library. I really like this approach since apart from some
make-foo to get the library compiled and linked with each
of modules, the rest is pretty much trivial. This avoids
API/dependency overhead. With things like
link-time-optimization becoming de-facto standard in the
next 2-3 years would give the best possible performance
with very small size overhead. Also works great for useful
functions that are too small for an API (for
example function to convert binary into hex and the
likes). <br>
</div>
</div>
</div>
</div>
</blockquote>
<p>I like this approach best, but let me suggest an improvement! If
you place the code under and extra directory level, e.g. in <b>lib/auth/</b>
instead of just <b>lib/</b>, <i>it will not compile by default!</i>
This way, any modules requiring digest auth-related DS and
functions will simply include the <b>lib/auth/auth.h</b> header
and have everything they need. See the <i>modules/registrar/Makefile</i>
for an example of how to include some "extra core source code"
into your module.<br>
</p>
<pre class="moz-signature" cols="72">--
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a></pre>
</body>
</html>