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

List:       kde-core-devel
Subject:    Re: [PATCH] Request for adding internal meta-data support to KIO...
From:       Dawit A <adawit () kde ! org>
Date:       2010-04-28 15:23:54
Message-ID: 201004281123.54831.adawit () kde ! org
[Download RAW message or body]

On Wednesday, April 28, 2010 08:03:00 Andreas Hartmetz wrote:
> On Wednesday 28 April 2010 07:06:35 you wrote:
> > Purpose:
> > ======
> > Allow io-slaves to send meta-data to one another that is not accessible
> > from the application level.
> > 
> > Reason:
> > =====
> > This patch actually grew from a need to fix authentication caching issues
> > in kio_http. Let me explain a little about the problem to make it crystal
> > clear why such a solution is essential. kio_http like every other ioslave
> > uses kpasswdserver to store and retrieve authentication information which
> > currently is accessed over dbus from KIO. Nothing wrong with that except
> > kio_http needs to query this service each and every time it processes a
> > request. It needs to do this because it wants to preemptively send
> > authentication header and avoid round-trips to sites the user had already
> > already authenticated to. However, doing so would have meant sending
> > gazillion requests over dbus.
> > 
> > That brings us to the problem... When kio_http was rewritten/updated for
> > KDE 4.x, the idea of preemptively sending authentication header was put
> > aside to avoid the unnecessary abuse of the dbus resource. Instead,
> > kio_http was changed to always wait for a 401/407 response from the
> > server before attempting to send any authentication header.
> > Unfortunately, that breaks things in in more ways than one. Not only
> > does opting to wait for a response from the server causes three or more
> > round trips to access every resource from a protected website now, but
> > it also breaks sites that rely, correctly I might add (see RFC 2617), on
> > the fact that once authenticated, the client will cache and preemptively
> > send back the authentication header whenever appropriate. In other
> > words, they do not expect yet another authentication again. See bug#
> > 181833 or the others marked duplicate of it.
> 
> Looks like I didn't read the RFC very thoroughly ;)

Yes, you did not. For shame for shame for shame ;) 

> > Solution:
> > ======
> > The obvious solution to the problem described above is to have the first
> > ioslave that successfully authenticates against a protected website
> > somehow communicate this fact to all other io-slaves that are going to
> > access a resource from this site. That way only those io-slaves would
> > know they need to check for cached authentication information and send
> > it preemptively, hence solving both of the problems for us...
> > 
> > What was surprising here is that the above solution can be implemented
> > very easily. With only one additional requirement to qualify meta-data
> > as internal, we can use the existing method that ioslaves use to send
> > meta-data back to applications to solve the issue. What is this
> > requirement ? We simply state/assume that a meta-data whose key starts
> > with the keyword
> > "_kio_internal_" will be treated as an internal meta-data and handled
> > separately from the regular meta-data container that holds values slated
> > to be sent to applications. You can read the details of how this is
> > supposed to work by either reading the attached patch or simply reading
> > the changes I made to the DESIGN.metadata document which is included
> > with the patch.
> > 
> > Comments, objections, suggestions are all welcome...
> 
> Thanks for the informative write-up.
> I'd rather add a new KIO command code. That would be safer (credentials can
> never mix with other metadata) and cleaner.
> When sending the HOST command the scheduler or some other central part of
> KIO could transmit the credentials just for that host. 

I think you misunderstood the intent of this solution as applied to the 
authentication caching dilemma in kio_http. The point is not to send 
credential information between ioslaves. Not at all. That defeats the purpose 
of having kpasswdserver and storing sensitive information in kwalletmanager.
Rather it is used to inform the other kio_http ioslaves that there is cached 
authentication information for that site so that they check for cached 
authentication information themselves and preemptively send it if present.

Let me go through the scenario of how kio_http would use this proposed patch..
Once the user successfully authenticates, kio_http caches the authentication 
data in kpasswdserver. In the section of kio_http code that does that, you 
simply set an internal meta-data as follows:

setMetaData("_kio_internal_0_cached-www-auth", "true");


That information is captured by the scheduler and then sent to all the 
appropriate slaves. In this case, because "0" is used the meta-data minus the 
internal keyword will be retransmitted only to those ioslaves that will be 
processing requests from the the same protocol (http) and host. 

This meta-data is then used to determine whether or not authentication 
information should be preemptively sent or not in the "authenticationHeader" 
function as follows:

if (config()->readEntry("cached-www-auth", false)) {
   go thru the process of checking for cached authentication here...
   ...
   ...
}

The beauty of this is that, the meta-data will only be sent to the appropriate 
io-slaves by the scheduler configuration and the flag used (0 or 1) when setting 
the internal meta-data. Does that clarify things for you ?

The other benefit of this patch is that other ioslaves can solve similar 
problems without resorting to additional hacks. Write it once and forget it. 
The mechanism allows you to exchange data between ioslaves just like you can 
between applications and ioslaves without having to write a single line of 
code yourself to accomplish that...

> This may or may not get tricky with redirections (I haven't looked at any
> relevant code recently). 

If you are talking about my solution, it works fine with redirections. I have 
already tested it. I did not post the related kio_http patch that exercises  
this patch, but re-directions are handled fine as well.

> Redirections have been the most productive source
> of hard to catch bugs in my KIO adventures...

Yes, I know :) The immediate "server timeout" bugs that people complain a 
whole lot about seem to emanate from redirections as well. Actually 
redirections mixed with keep-alive, but that is another topic all together and 
very hard to debug and resolve...

> In your patch I don't see mechanisms to send credentials to slaves created
> after the first slave has been asked for credentials, to update already
> running (not idle) slaves that haven't been asked for credentials yet, or
> any kind of credentials lifetime management.

See above. The intent of the patch is not to send credentials ; so credentials 
lifetime management does not apply. The updating of non idle io-slaves seems a 
futile attempt to me since it would be too late since they would be in the 
middle of processing a request already., but that can be investigated and 
resolved as needed. I am not as familiar with your rewrite of the scheduler 
code ; so I did not know where to find those io-slaves...

> These are the hard parts. So, using the hardest-part-first approach: how
> shall we manage the lifetime and propagation of credentials?

Does not apply... See above :) 

> Adding a new command or not will be easy.

Hence no need to do that... Yay! Always remember that an old KDE hand like me 
personally hates to reinvent the wheel!! My motto is to use what is there 
already and always always write as little code as possible to solve problems!! 
Less code, less bugs I have to deal with.

Regards,
Dawit A.
[prev in list] [next in list] [prev in thread] [next in thread]