cpp-netlib-devel

[cpp-netlib-devel] authentication and project files

[Stjepan R. <st...@as...>]

Hi all,

I just took a quick glance at the code, and am wondering how
authentication will be addressed in the library (since that's my main
interest :-))

For HTTP and SMTP this might not be an issue, but looking ahead what
are the thoughts on this?  Will the user just put together a message
which contains the necessary information in the headers / body, and
send it off through an appropriate authentication object, or will
there be a separate layer that takes care of the authentication?  A
related issue is how lasting connections will be handled.

Also, I've been working on the template-based generator for
boost/sandbox projects - once we've checked that it actually complies
with Boost guidelines, I can generate some IDE projects (for msvc and
xcode) and fill-in-the-blanks docs / doc-build-files for this project.
 Any problems with me adding that when it's ready?

Regards,

Stjepan

Re: [cpp-netlib-devel] authentication and project files

[Dean M. B. <mik...@gm...>]

Hi Stjepan!

On 5/22/07, Stjepan Rajko <st...@as...> wrote:
> Hi all,
>
> I just took a quick glance at the code, and am wondering how
> authentication will be addressed in the library (since that's my main
> interest :-))
>

The short answer would be, that it should be handled on a per-protocol
basis. We can definitely use the boost::network::message to contain
the necessary information to be dealt with by the protocol
implementation.

So if there's a protocol like SMTP where there's a need for a username
and password, my suggestion would be that there should be a
"boost::network::smtp::credentials" object which encapsulates that
information.

> For HTTP and SMTP this might not be an issue, but looking ahead what
> are the thoughts on this?  Will the user just put together a message
> which contains the necessary information in the headers / body, and
> send it off through an appropriate authentication object, or will
> there be a separate layer that takes care of the authentication?  A
> related issue is how lasting connections will be handled.
>

As for lasting connections, Boost.Asio already provides stuff that can
be re-used and simply re-worked and packaged so that they're used in a
more generic way (instead of having to implement the same keepalive
implementation on all applications that need this functionality or
something similar).

> Also, I've been working on the template-based generator for
> boost/sandbox projects - once we've checked that it actually complies
> with Boost guidelines, I can generate some IDE projects (for msvc and
> xcode) and fill-in-the-blanks docs / doc-build-files for this project.
>  Any problems with me adding that when it's ready?
>

I don't know what you mean, but when we do have the code to build in
different platforms (I'm guessing we won't because I intend to keep
this library "header only") then things like that would help. For now
though, I'd rather stick with Boost.Build + Boost.Test for the
testing, maybe some Quickbook + doxygen for the documentation, among
other things.

We'll see if we can use the stuff you're working on too -- if it can
help us write better docs quickly, then I guess we should definitely
go for it. :)

Thanks much! :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] authentication and project files

[Stjepan R. <st...@as...>]

Hi Dean, thanks for your response:

On 5/23/07, Dean Michael Berris <mik...@gm...> wrote:
> On 5/22/07, Stjepan Rajko <st...@as...> wrote:
> So if there's a protocol like SMTP where there's a need for a username
> and password, my suggestion would be that there should be a
> "boost::network::smtp::credentials" object which encapsulates that
> information.
>

OK, I like this. :-)  Keeps things consistent.

> > there be a separate layer that takes care of the authentication?  A
> > related issue is how lasting connections will be handled.
> >
>
> As for lasting connections, Boost.Asio already provides stuff that can
> be re-used and simply re-worked and packaged so that they're used in a
> more generic way (instead of having to implement the same keepalive
> implementation on all applications that need this functionality or
> something similar).
>

Sure.  Maybe I'm not getting your answer fully, but what I meant was
keeping track of the state of a long lasting session (you use a
session as an example in another e-mail which I quote below).  For
example, if I open an FTP connection, and the first thing I send is a
'credentials' message, the protocol should log in using the
credentials.  If instead, the first thing I send is a request for a
file, maybe the system should try to log me in as anonymous and then
get the file.  Similarly, if I send a 'credentials' message after
already being logged in (either as anonymous or via some other
credentials), there is a different sequence of actions needed than the
one used when credentials are sent at the beginning of the connection.

So, my question was, how do we keep track of a long lasting session
and its internal state, which determines how exactly different
messages are handled at the moment.  In your example, you have:

> { // open a scope for the smtp connection
>   smtp::session my_persistent_session(smtp::server("mail.google.com",
> 575, boost::network::tls), smtp::credentials("username", "password"));
>   boost::network::message m;
>   m << header("To", "mik...@gm...")
>     << header("From", "so...@th...mewhere.nw")
>     << destination("mik...@gm...")
>     << source('so...@th...mewhere.nw")
>     << header("Subject", "This is a test message.")
>     << body("The quick brown fox jumps over the lazy dog")
>   ;
>   for (unsigned int i = 0; i < 100; ++i) // send 100 times
>     smtp::send_message(my_persistent_session, m);
> } // close the scope for the smtp connection
>

, so this makes things a lot clearer for me (although, I think I would
prefer my_persistent_session.send_message(m);  since the session knows
what protocol to use.)  To add, I think it would be important to have
a set of generic templates for session classes, both to ease our own
development of many protocols, and to allow users to easily conjure up
their own protocols.  Something that covers cases like "authentication
must come at the beginning, then every other message is OK".  Perhaps
a generic session can be modeled as a map (state, message) -> handler.

> > Also, I've been working on the template-based generator for
> > boost/sandbox projects - once we've checked that it actually complies
> > with Boost guidelines, I can generate some IDE projects (for msvc and
> > xcode) and fill-in-the-blanks docs / doc-build-files for this project.
> >  Any problems with me adding that when it's ready?
> >
>
> I don't know what you mean, but when we do have the code to build in
> different platforms (I'm guessing we won't because I intend to keep
> this library "header only") then things like that would help. For now
> though, I'd rather stick with Boost.Build + Boost.Test for the
> testing, maybe some Quickbook + doxygen for the documentation, among
> other things.

The IDEs generated actually build everything (lib if applicable,
tests, examples) using bjam.  They just provide the utility of an IDE,
which I like.  If other people also use IDEs it might be useful to
have the IDE projects in the subversion, so everyone doesn't have to
make their own.

I can certainly add the build files for a qb+doxy documentation and a
template for docs themselves... soon :-)

Cheers,

Stjepan