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. 0006 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. 0010 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. 0016 0017 Dawit A. <adawit@kde.org> 0018 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. 0032 0033 Let me try to draw the situation I had in mind when writing this: 0034 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 0055 0056 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. 0065 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). 0073 0074 Waldo Bastian <bastian@kde.org>