Há um tempo utilizo este script bash para instalar o Skype num box Fedora e ele tem funcionado muito bem. A instalação por ele traz recursos como Skype Video funcionando de forma perfeita, então, passou da hora de compartilhar :-).
Eu gostaria de lhe apresentar geeklist-php. Esta biblioteca LGPL é capaz de retornar o conteúdo dos “Cards” de um username da rede social Geekli.st e retorná-los como uma string JSON ou um array simples para você. O truque desta lib é que ela não requer uma API do Geeklist para funcionar.
A intenção é que ela seja 100% aderente aos recentes padrões PSR-[0|1|2], traz um autoloader para tornar o trabalho com ela mais simples, e está pronta para usar com o Composer. Simplesmente adicione no composer.json de seu projeto:
Pegue-a, faça fork, use-a, melhore-a! À primeira vista, pode-se notar a falta de PHPDoc no código.
I’d like to present you geeklist-php. This LGPL library is able to fetch cards content of a given/valid username on Geekli.st social network, and return them as a JSON or simple array for you. The trick in this library is it does not require an API key from Geeklist.
It intends to be PSR-[0|1|2] compatible, brings an autoloader to make the work easier, and is ready-to-use with Composer. Simply add in the composer.json of your project:
Get it, fork it, use it, improve it! On the first sight, is possible to notice lack of phpdoc on the code.
At first sight, the idea is excelent and simple. It offers an easy alternative to be built, more secure, portable and decentralized. More one alternative for the OpenID and oAuth, with the advantage of almost everyone have an e-mail account, thus being able to deal with these much more naturally.
In your proposal, the Mozilla Labs suggests the authentication be done with first factor, using any e-mail address of the user as your identity. Say also that the authentication be decentralized and server based, instead of domain and website based. This method free the applicaton of saving the login and password attributes of the user, and the users of saving the same for each service they use on the web.
The user browser manages the authentication artifacts locally (all of them accessible via DOM with [window|session].localStorage). So you won’t see anything related to certificates and security devices;
The authentication pop-up is built in HTML5.
Ease of implementation;
Short lifetime for the public / private key (only few hours);
Shows the e-mail user to the website that is authenticating it. There is not a side effect or something unexpected, to inform the e-mail towards the website is an architectural decision made by the staff of Mozilla Labs and explained by Ben Adida. OpenID takes an advantage here because it does not reveals the e-mail user for the application;
There is not a way to logout, it must be done on the application side invalidating the session data;
The usability of the feature bothers me at some points, for example triggering a pop-up and the procedure adopted at the first time of the user on the feature;
Another annoyance is about the decentralization. If there is more than one authentication point, how the whole stuff works when the user navigates within different points of authentication?
The idea is great, my first feeling was, “Is that all?” so simple that is. Despite having more cons than pros I feel I would make available this login way if I had the chance. I’m hoping that there are more authentication providers to enforce the effect of decentralization.
We must remember that this mechanism is only a part of the process: is the authentication. The work of identification and authorization of the user must be accomplished by the application yet.
Do you wanna test it?
I tested the engine in my virtual garage (it is also its inauguration, a place where my code could be tested “@live”). Besides my garage, the Mozilla website offers the MyFavoriteBeer, a place where the login process is working with this feature.