Does not work with Thunderbird LDAP

[GoogleCodeExporter]

From 
https://addons.mozilla.org/addon/keychain-services-integration/reviews/325987

One minor bug is that it does not work with Thunderbird's integrated LDAP 
support. It seems that the built-in URI parser you used does not accept the 
ldaps scheme. I've replaced the functions _uri and _url in 
modules/MacOSKeychain.jsm with the following quick-and-dirty parsing code and 
it works like a charm:

function _uri (uriString) { return _url(uriString); }
function _url (urlString) {
       if (!_url.parser) _url.parser = /^(https?|ftps?|irc|nntp|pop3s?|imaps?|ldaps?|afp|ssh|smb|ipps?|svn|smtps?):\/\/(?:[-a-z0-9.]+(?::[^@\s]+)?@)?([a-z0-9](?:[-a-z0-9.]*[a-z0-9])?)(:[0-9]{1,5})?(?:\/[^\s]*)?$/i;
       var match = urlString.match(_url.parser);
       if (!match) throw Error("Not a valid url: " + urlString);
       var port = -1;
       if (match[3]) port = match[3].substring(1, match[3].length);
       return {
                       scheme: match[1],
                       host: match[2],
                       port: port,
                       spec: urlString
               };
}

Original issue reported on code.google.com by jfitz...@gmail.com on 11 Jan 2012 at 5:41

[GoogleCodeExporter]

Mozilla documentation of nsURI gives not indication that LDAPS is not 
supported: https://developer.mozilla.org/en/nsIURI

I'll need to test further - this may be an upstream bug or an error in how the 
interface is being used. I'm reluctant to rely on regular expressions unless 
absolutely necessary...

Original comment by jfitz...@gmail.com on 11 Jan 2012 at 5:51

[GoogleCodeExporter]

Original comment by jfitz...@gmail.com on 11 Jan 2012 at 5:51

[GoogleCodeExporter]

Had a quick look at this...

I think the problem may be that splitLoginInfoHostname() is using _url() 
instead of _uri() for parsing. As I recall, the reason for that is that it was 
an easy way to fix the problem of Sync URLs having a schema not supported by 
Keychain Services. By trying to coerce to a URL, the sync URLs appear invalid 
and we fall back on the old password store.

The *correct* solution to that is to check for incompatible schemas and use an 
application password instead of an internet password in that case - at which 
point the "fix" could be reverted.

There may also be a better intermediate fix, though if anyone's going to spend 
any effort, it might be worth doing it right in the first place.

Original comment by jfitz...@gmail.com on 11 Jan 2012 at 7:12

[GoogleCodeExporter]

Fixed in 1.1.3

Original comment by jfitz...@gmail.com on 12 Jan 2012 at 11:23

• Changed state: Fixed