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

List:       kde-core-devel
Subject:    Re: Authentication and kio_http
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2000-06-14 8:20:50
[Download RAW message or body]

On Wed, 14 Jun 2000, Waldo Bastian wrote:
> On Tue, 13 Jun 2000, Dawit Alemayehu wrote:
> > On Tue, 13 Jun 2000, Kurt Granroth wrote:
> > > Waldo Bastian wrote:
> > > > On Tue, 13 Jun 2000, Kurt Granroth wrote:
> > > > > Are there any http experts that know of a really quick fix for this?
> > > >
> > > > I rather have a proper fix than a quick fix.
> > >
> > > Yep... I wanted a quick proper fix :-)
> > >
> > > > So it seems that we need for authentication a mechanism similair as the
> > > > one used for cookies: before the slave requests a page it must ask a
> > > > central authority (kdesu?) for any credentials to send along.
> > >
> > > Yes.  There is code already for doing this in SlaveBase::openPassDlg.
> > > Unfortunately, you can't just call this function randomly... it will
> > > pop up a dialog if there is no cached authentication stuff.
> > >
> > > So it appears that either we need to move some of the code into
> > > kio_http (bleah) or move the code into a separate public or protected
> > > function and have both kio_http and openPassDlg call it (yeah?)
> >
> > Where ?? In its own class ??
> >
> > > Does that make sense?
> >
> > Here are the problems that you would face no matter what
> >
> > 1.)  How do you determine whether or no a particular request needs
> > authentication ?  There is no guarantee the same slave would be used
> > to process the request so a new slave would have no clue about the type of
> > authentication to use or the value of the realm !!  This is the major
> > problem caused by the flexible design of the io-slaves...
> >
> > 2.) How can you use the services of kdesud daemon without creating a
> > dependency b/n the libkio & libkdesud ??  Or should we scrap this and
> > create another dcop server that can be used to store such things ??
> >
> > 3.) How can you provide the password/authentication daemon to other
> > io-slaves ??
> [Snip]
> > When you consider the above questions it is not as easy to resolve this
> > solution.   I think we need to discuss this.  In fact I am stuck the same
> > way about provide a framework for SSL verification ??  How do you notify
> > the client app to show certain information.  So far I cannot find any
> > solution without creating yet another server !?!?  Anyways, either the
> > quick-fix route or the proper-fix route the problem is not as easy to deal
> > with.  But then again ...
> 
> I think these problems are basically similair to the problems surrounding 
> cookies so the solution should probably look similair as well. You need a 
> central server which handles this stuff. Currently we seem to have 3 central 
> servers: 
> *) uiserver
> *) kcookiejar
> *) kde_su
> 
> And if we continue this way we will have an additional SSH verification 
> server and a HTTP authentication server. So I guess it is time to do some 
> structuring.... something like:
> 
> 1) kde_su basically seems to act as a "safe" to store passwords in.
> 
> 2) uiserver offers user interface facilities for servers that don't tend to 
> have a user-interface of their own.
> 
> 3) kcookiejar, the future SSH certificate verifier and the HTTP authentication
> server offer centralized protocol specific lookup functionality.
> 
> It is tempting to move e.g. the UI part of the cookiejar to the uiserver, on 
> the other hand, the UI of the cookiejar is very much dedicated to the 
> cookiejar only. Doesn't seem to urgent right now.
> 
> Do we want to have 5 servers running or do we want to combine them somehow? 
> Basically we can start them only when needed, if you never use a web-site 
> that requires authentication we don't need to start the HTTP authentication, 
> if you don't want to use cookies, we don't need the kcookiejar, if you don't 
> use https servers, you don't need the SSH certificate server.
> 
> 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?

Well what I was thinking was that we can abstract out all the ui stuff into
the ui_server and lump everything else into one daemon. This means
authentication/verification/session-management (cookies) would be
grouped together and accessiable from an on-demand daemon ??  I do
not know if this would be feasible or even adviseable but it sure would cut
down on the number of servers created.  I guess the cookiejar would be a good
starting point for this ??

Regards,
Dawit A.

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