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

List:       kde-core-devel
Subject:    Re: Authentication and kio_http
From:       geertj () stack ! nl (Geert Jansen)
Date:       2000-06-15 7:53:42
[Download RAW message or body]

> On Wed, 14 Jun 2000, Kurt Granroth wrote:
> > Waldo Bastian wrote:
> > > On the other hand the functionality offered by the HTTP
> > > authentication server is not that much (maybe 40 lines of code?) so
> > > it is tempting to combine it with something else... but what? The
> > > cookiejar? Maybe we should rename it into the "httpdaemon" then? Put
> > > it in the kio-lib? The HTTP authentication would be bound to the
> > > application then, but this is probably not to bad.  Putting it in
> > > kde_su is a bad idea because we want to have as little as possible
> > > in that process. The uiserver doesn't seem to be an attractive
> > > place... although it tends to be running anyway. Ideas anyone?
> >
> > Why is using kdesu a problem?  We already *are* using it for HTTP
> > authentication a little.... I don't see why we can't extend it to do
> > SSL certificates as well.
> 
> kde_su only stores stuff but it doesn't know anything about specific 
> protocols. That's why it isn't sufficient for HTTP authentication either.
> (At the moment it is, but not if we want to send authentication info in 
> advance)
> 
> That's not so much a problem in kde_su. It just isn't intented for such kind 
> of use.

You could fold all the keys needed to identify the security token into a string, 
and then use that as the index. You do have to be carefull that no two different
key sets end up in the same string, however. 

Would it be usefull to have a "namespace id" of one integer associated with each 
stored key? The dameon already uses namespeces internally to hold the "su" and 
other keys apart.  It would be little work to offer this feature to the client side.

But maybe it is better not to use kdesud at all, I'm not sure. One thing is the
nonstandard communications channel between client and server (/tmp socket). It won't
work distributed like DCOP does.

Greetings,
-- 
    Geert Jansen,                                email: <geertj@stack.nl>
    Phylosopher and Physicist                      PGP key ID: 0xD2B5E7CE

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