[Webkit-unassigned] [Bug 83259] [BlackBerry] Networking - Assertion failed when it store FTP credentials

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 11 09:19:01 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=83259





--- Comment #7 from Brady Eidson <beidson at apple.com>  2012-04-11 09:19:01 PST ---
(In reply to comment #4)
>There are 3 type browsers which support FTP credential storage. They are Firefox 11.0, Chromium 18.0 and IE 8 as I tested. So I think storing the FTP credentials makes sense.

Why do you think only those 3 browsers support FTP credential storage?  All Mac WebKit browsers do, for example, by virtue of using the keychain for persistent credential storage and having the networking layer and/or the browser itself try that keychain.

Also it's not clear to me based on your statement but it seems possible that you think the credential store is persistent, while it is not.

> (In reply to comment #3)
> > (From update of attachment 135975 [details] [details])
> > I think that the correct answer is to not use HTTP credential storage code for ftp. It's specifically tailored for HTTP credential semantics.
> 
> Currently, only the CF and BlackBerry porting are using the CredentialStorage as I grepped CredentialStorage::set. 
> ...
> What is your concern?

Our concern - that Alexey explicitly stated - is that the CredentialStorage class is used solely for HTTP(S) credentials and has the semantics of that usage.

You're also mistaken about how "limited" the use is:

`grep -r "CredentialStorage::set" . | grep -v ChangeLog`
./WebCore/platform/network/blackberry/NetworkJob.cpp:    CredentialStorage::set(challenge.proposedCredential(), challenge.protectionSpace(), m_response.url());
./WebCore/platform/network/cf/ResourceHandleCFNet.cpp:            CredentialStorage::set(Credential(d->m_user, d->m_pass, CredentialPersistenceNone), firstRequest().url());
./WebCore/platform/network/cf/ResourceHandleCFNet.cpp:        CredentialStorage::set(core(credential.get()), challenge.protectionSpace(), urlToStore);
./WebCore/platform/network/cf/ResourceHandleCFNet.cpp:                    CredentialStorage::set(credential, challenge.protectionSpace(), challenge.failureResponse().url());
./WebCore/platform/network/cf/ResourceHandleCFNet.cpp:        CredentialStorage::set(webCredential, challenge.protectionSpace(), urlToStore);
./WebCore/platform/network/CredentialStorage.cpp:void CredentialStorage::set(const Credential& credential, const ProtectionSpace& protectionSpace, const KURL& url)
./WebCore/platform/network/CredentialStorage.cpp:bool CredentialStorage::set(const Credential& credential, const KURL& url)
./WebCore/platform/network/mac/ResourceHandleMac.mm:            CredentialStorage::set(Credential(d->m_user, d->m_pass, CredentialPersistenceNone), firstRequest().url());
./WebCore/platform/network/mac/ResourceHandleMac.mm:                    CredentialStorage::set(credential, challenge.protectionSpace(), challenge.failureResponse().url());
./WebCore/platform/network/mac/ResourceHandleMac.mm:        CredentialStorage::set(webCredential, core([d->m_currentMacChallenge protectionSpace]), urlToStore);

In addition to BlackBerry it is used by Windows, Mac, and iOS ports..  In fact it was added for the mainline Apple ports.

We apologize for the confusion that this is a generic credential store when - as stated a few times - it is explicitly about HTTP credentials.  I've filed https://bugs.webkit.org/show_bug.cgi?id=83695 to correct that so no one makes the same mistake again.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list