Re: [PEPr] +1 for Networking::Net_WebFinger

From: Date: Fri, 17 Feb 2012 14:35:20 +0000
Subject: Re: [PEPr] +1 for Networking::Net_WebFinger
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-54827@lists.php.net to get a copy of this message
Hello Till, > 1) What I'm not so sure about is the request code in the > Net_WebFinger class. Some of the methods seem long and a little > redundant in terms of code. > > Maybe spin it off into a dedicated request class. I have no idea yet, > if you catch my drift, maybe you can improve this, otherwise I'll > take a look later and will send you a pull request. I know what you mean and already thought about this, but consider one: the class Net_WebFinger has only one task, it's to deliver the reaction object. Since there is nothing more it has to do, having the network request code in there is ok in my eyes. > 2) Net_WebFinger::finger() should IMHO throw an exception if no '@' is > found. In the identifier? Hm. Didn't think of that yet :) > 3) I'd see if you can use Net_URL2 (which comes with HTTP_Request2) > for the "isHttps()" check. Speaking of which, is SSL usually a given > with these things or the exception? If most of the resources are > non-SSL, I'd run the non-SSL request first. Otherwise it'll be pretty > expensive. > > And/Or offer a way to force "non-SSL" lookup (with finger()). Webfinger maps an email address to an openid, which is something that's a target of hijacking (if I were an attacker). If I can move any address to my own openid provider, I've won. So using a secure channel first is the best thing to do. Non-SSL is only a fallback. The WebFinger specs recommend that behavior. > 4) I'm not so sure if I like Net_WebFinger_Error. Are all errors > usually to be disregarded? Is that why you don't throw Exceptions? Or > is there another reason I am missing. Not many hosts have webfingers yet, and not all webfinger/lrdd files have the same features/links. My idea of the package was to make discovery extremely easy, and it should not get in your way. If you want an openid, just do > $wf->finger('user@host')->openid and nothing more. You don't care if there are errors, because the openid is null if it can't be found. If you really care about the errors, which most people don't, because they just want the openid, you can still access it via the error property. That's the reason for no exception throwing: Don't get in the way, but provide enough information for a detailled analysis. > 5) I'd like to see an autoloader. I'm not sure why you think PEAR1 > cannot have this. Especially with a 5.3 minimum, require_once seems > really outdated and would force me to fork for my own uses to use > another class-loading strategy. > > Imho, an autoloader could take care of all that. Enabled by default, > and if people want to run their own, they could disable it. Then > there's no need to strip require_once. Should we use the PEAR2 autoloading rules then? > 6) Careful on the dependency on Cache. ;) (I think we need to work on > something there and bring the code up to date.) It's optional, so I don't see a problem. Using Cache_Lite was not possible unfortunately, and we don't have anything else. -- Regards/Mit freundlichen Grüßen Christian Weiske -=≡ Geeking around in the name of science since 1982 ≡=-

Attachment: [application/pgp-signature] signature.asc
« previous php.pear.dev (#54827) next »