Warning, /frameworks/kio/src/kpasswdserver/DESIGN is written in an unsupported language. File is not indexed.

0001 Credentials storage duration
0002 ============================
0003 How long credentials are stored depends on a couple of factors. The first is
0004 whether a window-id (see QWidget::WId) was provided when the password request
0005 was made. The other is the state of KIO::AuthInfo's keepPassword flag.
0007 If the window-id parameter is missing, the credentials are stored for the
0008 entire duration of the current KDE session. Otherwise, they are only kept
0009 until the application(s) associated with the window-id exit.
0011 The "keepPassword" flag on the other hand only matters for caching credentials
0012 in a persistent storage such as KWallet. If this flag is set to false, then
0013 credentials are only kept in memory based on the value of window-id as discussed
0014 above. See the documentation for the "keepPassword" property in KIO::AuthInfo
0015 for more details.
0017 Dawit A. <adawit@kde.org>
0019 Sequence numbers
0020 ================
0021 The idea is that whenever the user is queried for a password this
0022 login/pw combination gets a seq-nr. When  a worker needs a  login/pw
0023 it asks kpasswdserver and sends along the last seqnr it received. If
0024 this seqnr is older (lower) than the seq nr of the login/pw
0025 combination stored in kpasswdserver then apparently the user has
0026 already been prompted for a new login/pw combination since the last
0027 time this worker asked for a login/pw and therefore it is not necessary
0028 to prompt the user again but kpassword will send the KIO worker this
0029 new login/pw combination. If this new combination fails as well the
0030 user is being prompted for a new login/pw combo since the one stored
0031 in kpasswdserver doesn't work.
0033 Let me try to draw the situation I had in mind when writing this:
0035 Worker1         Worker2                 kpasswdserver
0036 Asks for auth
0037                                         asks user for login/pw (1)
0038 sends login/pw (1) to ftp site
0039                 Asks for auth
0040                                         sends back login/pw (1)
0041                 sends login/pw (1) to ftp site
0042 gets login error,
0043 asks for new auth
0044 sends along seq.nr 1
0045                                         seq.nr 1 == (1) -->
0046                                         asks user for new login/pw (2)
0047 sends login/pw (2) to ftp site
0048                 gets login error,
0049                 asks for new auth
0050                 sends along seq.nr 1
0051                                         seq.nr 1 < (2) -->
0052                                         don't ask user for new login/pw
0053                                         but send back login/pw (2) without asking
0054                 sends login/pw (2) to ftp site
0057 Actually, I had mostly http in mind, and not so much ftp. In http you 
0058 typically try without password first, and only when you get an 
0059 authentication error you ask for a password. The above scenario is 
0060 then suddenly a lot more common than with ftp because it can happen 
0061 that you have 4 requests /workers who all discover at about the 
0062 same time that they need to have authentication credentials. The 
0063 above scenario (and the seq. nrs) is to prevent that you get 4 login 
0064 dialogs in such case.
0066 Now the assumption in this all, looking back on it, seems to be that 
0067 when you ask for the same auth credentials twice in a row, it must be 
0068 that the credentials issued the first time where wrong, and you will 
0069 be prompted again. But if the user goes to ftp-site1, then 
0070 ftp-site2 and then back to ftp-site1 again, the credentials for ftp-site1
0071 are still valid. This is why we reset the seq.nr stored in the KIO worker
0072 to 0 whenever the KIO worker switches hosts (or logins).
0074 Waldo Bastian <bastian@kde.org>