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

List:       kde-core-devel
Subject:    Re: Authentication and kio_http
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-06-14 6:01:55
[Download RAW message or body]

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?

Cheers,
Waldo
-- 
Make way, KDE/Linux is coming to a desktop near you!

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