[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Alex's KSASL Modification (Was MD5 stuff)
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-01-05 5:56:35
[Download RAW message or body]

Hello,

Hmmm... did not see this mail until now...

> Well it is, for interactive protocols.  HTTP is an odd duck in that it is
> generally one command per connection... also most protocols (SMTP, POP,
> IMAP) have been extended to support SASL (e.g. they list the supported
> SASL auth methods in a standard way, etc).  HTTP does not do this.

I see what you mean now.  It is just that I simply slow by nature :)

> > And I was so hoping that we can have one layer for all protocols to use
> > to avoid duplication.  Oh well...
>
> HTTP is somewhat of the black sheep here.

:)

> > Digest is another issue though and would be nice if a common ground can
> > be found for it...
>
> I've had a lot of trouble testing it..  But theoretically it should be
> possible to share a codebase.. and even use the SASL API, but I look at
> using the SASL class(es) as abuse, and IMO would require too much hacking.
> Sharing the same digest implementation is a thought, but logistically
> tricky.  I'd be fine with no digest support.  Even MSIE supports it in a
> rather awkward way.

Reasonable, but it feels like we are probably postponding the inevtiable ??  Sooner
or later it would be adapted since it is much better than CRAM-MD5.  But I am sure
by then there will more specifications to deal with this issue ??

> > Hehe.. and I thought I was doing the easier part.  Now you tell me...
>
> Signedness and character arrays.. ugh.  It was so much easier to port
> CRAM-MD5 ;)

:)

> OBTW, most popular mail clients (not based on Cyrus-SASL) support CRAM-MD5
> and not DIGEST-MD5.
>
> > Are they really that different ?
>
> No, they aren't, in fact the more recent one was designed to be 100%
> backwards compatible.  But the quality of the HTTP implementations varies,

This is true and probably due to the fact that a very small number of servers support
Digest Authentication.  

> and they are all different enough.. and that one server didn't deal well
> with netcat making it that much harder to test things.  I just gave up.

You are not alone.  I have been fighting the same thing for a while.  I am at the point
where I am going to email the webmaster and ask him for info on the logs he is getting.
A stuipd 400 can only mean so many things specially for authentication.  May be that
server implements the older version of this specification ??  Anyways, I have problems
with the one supplied by belllabs as well so I do not know what is going on, but I sure
am going to look at RFC 2069 which 2617 obseleted...

> > That is just it.  I mean my dilema right now.  There is nothing else
> > that uses this library now except the io-slaves.
>
> Right.. and if the need arises the classes can be moved later, no?

Right, so it is going to KIO for now...

> > Hmmm... there are applications that do not need network transparency
> > though.
>
> Not necesarily.  Network transparency would mean every file based object
> becomes a url object... anything that uses KApp uses KConfig.. and KConfig
> uses files.  KIconLoader... etc.  Yes, larger libraries (esp. C++) will
> slow loading.  But if it's already linking in kio....

Well that is a good argument, but so is the other way around specially since people
complain very much about preceived speeds nowdays.  Anyways, I am sure this is
something that will be discussed down the line since these libarries are not getting
any slimmer...

> > Should this be a "Singleton" object ?
>
> IMO, no.
>
> > I mean do people need to get multiple instance of the KSASLContext object
> > ?
>
> One instance per connection is all that's allowed.  However, I can't
> imagine a scenario that would need multiple connections in one app
> (ioslaves are separate processes, no?), but I wouldn't like to rule out
> that possibility.  Especially with the mess that is static ctors/dtors.
> However, there *is* a need (well, desire) for a persistant object in the
> cases of the authentication methods like digest-md5 which allow bits and
> pieces to be cached.

Okay, no problem.  Will move the ctor back and leave the static accessor then...

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]