[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 2:34:23
[Download RAW message or body]

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?)
>
> Does that make sense?

The stuff you are looking for is part of uiserver::authorize(), that needs to 
be moved to kio_http. You probably don't need to check for a running kdesu 
because if it isn't running we just wait for a 401 and when that happens it 
will be started as is done now.

The problem of that approach however, seems to be that we don't necasserily 
know the realm. E.g. we must look for any realm that is appropriate for our 
request, but the current design only allows us to test whether we have a 
password for a specific realm. 

E.g. we must transform a URL to a realm and based on that realm we can query 
for credentials. But we can't transform a URL to a realm because we a) can't 
query for a complete list of realms, b) don't store the URL for which a realm 
is valid.

> > From what I understand though it is not correct of Zope to depend on
> > credentials being in the first request. I haven't read RFC 2617 though.
>
> Well, most pages *do* work "correctly" by sending back a 401.
> However, as I said, certain pages use the authentication info for
> determining state (not sure why cookies aren't used).  Those pages do
> need the auth stuff on the first try.
>
> I am unsure whethere that is a design flaw in Zope or not.  I think
> they *should* use cookies...  Anyway, it doesn't matter -- we should be
> able to handle this.

Just reading RFC2617 which says:
   The protection space determines the domain over which credentials can
   be automatically applied. If a prior request has been authorized, the
   same credentials MAY be reused for all other requests within that
   protection space for a period of time determined by the
   authentication scheme, parameters, and/or user preference. 

It says "MAY" and not "MUST". So the fact that Zope depends on that seems to 
be a design flaw on the part of Zope. That doesn't mean that we shouldn't try 
to fix it on our part, but it might be nice if Zope did their part as well.

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]