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

List:       konq-bugs
Subject:    Bug#29955: multiple accouts per server password caching not working
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-07-30 4:46:55
[Download RAW message or body]

Hi Lucas,

Indeed I own you an appology.  You are right, my multiple password caching
was completely flawed.  It should not be fixed.  Please update kdelibs/kio/slavebase.cpp 
and try it again.  It should work correctly for all circumstances...

Thanks for the report.

Regards,
Dawit A.

On Sunday 29 July 2001 17:48, Lucas Fisher wrote:
> Dawit Alemayehu wrote:
> > Hi Lucas,
> >
> > On Sunday 29 July 2001 03:03, ljfisher@iastate.edu wrote:
> > > Package: kioslave
> > > Version: KDE 2.2.0 CVS/CVSup/Snapshot
> > > Severity: normal
> > > Installed from:    Compiled sources
> > > Compiler:          gcc
> > > OS:                Linux
> > > OS/Compiler notes: Not Specified
> > >
> > > ioslaves can cache multiple user/password pairs per server.  This
> > > feature is not working. You are asked for your password every time you
> > > switch between different users on the same server.
> >
> > Need details please.  Are you logging into the same machine ? Which
> > protocol is giving you the problem, ftp http ?
>
> It seems to be a general ioslave thing.  I discovered this while working on
> my sftp ioslave.
> The ftp slave exhibits the same behavior as my slave. Either we both are
> using the cache incorrectly or there is a problem with slavebase.  I
> haven't tested the problem with http.
>
> > > The problem lies in SlaveBase::checkCachedAuthentication().  When
> > > cacheMultipleAuth is enabled it saves the username with the key
> > > 'host:port:username-user'. But when this function goes to lookup the
> > > username to see if a password is cached for the user, it uses the key
> > > 'host:port-user'. As a result it doesn't find a cached entry for the
> > > right user.
> >
> > No that is wrong.  The look up uses the "group key" and not the
> > "individual entry keys" to look for cached login info.  If you check
> > ::cacheAuthentication again this corresponds to the grp_key entry.  So in
> > ::checkCachedAutnentication all entries that belong to this particular
> > group-key are iterated over to check for a match.
>
> They are not iterating over all every entry in the group.
> The code in checkCachedAuthentication is like:
> if( found group ) {
> if( count > 0 ) {
>   if( verifypath is set ) {
>      do some stuff
>      iterate over the list
>   }
>   else {
>     if( realm is empty )
> 	found = true
>     else
>        do some stuff
>   }
>
> }}
>
> The group is found but I don't set verify path, because I don't care about
> the path, nor do I set a realm.  So then execution reaches the following
> code segment:
>
> 1        QString stored_user = QString::fromUtf8(client.getVar( auth_key
> +"-user") );
> 2        bool emptyUser = info.username.isEmpty();
> 3        kdDebug(7019) << "info.username = " << info.username << "
> stored_user= " << stored_user;
> 4        if ( emptyUser || info.username == stored_user )
> 5        {
> 6            if ( emptyUser )
> 7                info.username = stored_user;
> 8            info.password = QString::fromUtf8(client.getVar( auth_key
> +"-pass" ) );
> 9            if ( info.realmValue.isEmpty() )
> 10                info.realmValue = QString::fromUtf8(
> client.getVar(auth_key +"-realm") );
> 11            info.digestInfo = QString::fromUtf8( client.getVar( auth_key
> +"-extra") );
> 12           kdDebug(7019) << "Found cached authorization for: " <<
> auth_key << endl
> 13                          << "  User= " << info.username << endl
> 14                          << "  Password= [hidden]" << endl
> 15                          << "  Realm= " << info.realmValue << endl
> 16                          << "  Extra= " << info.digestInfo << endl;
> 17            sendAuthenticationKey( auth_key, grp_key, info.keepPassword
> ); 18            return true;
>         }
>     }
>
> So it looks up the usename using the auth_key on line 1 using the key
> 'host:port-user'.
> Stored_user will be whoever's auth info was stored the last time
> cacheAuthentication was called, because the key does not include the
> username. Then the test at line 4 fails because info.username !=
> stored_user, because I am trying
> to login with a different username.
> Then checkCachedAuthentication returns false.
>
> > > This may be fixed by adding within the
> > > if( d->multipleAuthCaching && !info.username.isEmpty ) block:
> > > auth_key += ':';
> > > auth_key += info.username.utf8();
> >
> > Hmm... this looks like you have a problem using an empty username ?  Even
> > for
>
> No, the username is not empty.
>
> > an empty password however this should still work since the second entry
> > will be "host:port:-user" instead of "host:port-user".  Anyways,
> > something else is wrong here.  If you compiled with debugging enabled
> > please turn on debug areas 7019, 7103, 7113 using "kdeugdialog
> > --fullmode" and see what you get when you attempt to login.
>
> I've attached the debug output, but with kio_ftp debug enabled instead of
> kio_http since http hasn't been causing any problems I know of.
>
> > BTW, I cannot duplicate this here.  I just tested and I can login using
> > multiple accounts into my ftp and web servers without being re-prompted
> > for it...
>
> Here's exactly what I am doing and what happens:
> 1. into the location bar enter: ftp://alice@localhost
> 2. I am asked for alice's password
> 3. enter ftp://bob@localhost
> 4. I am asked for bob's password
> 5. enter ftp://alice@localhost
> 6. I am asked for alice's password
> 7. enter ftp://bob@localhost
> 8. I am asked fro bob's password
> 9. etc....
>
> Someone who is testing my slave noticed the same problem.
>
> Lucas

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