repoze.who would seem like the best candidate these days, it would be great to see that integrated, but I worry it would also cause lots of unintentional breakage in the corner cases.
On 05/03/13 17:09, James Taylor wrote:
On Mar 1, 2013, at 10:39 AM, Vipin TS <vipin.ts@gmail.com> wrote:
Hello members,How about some kind of captcha support?
I believe currently there is no process to validate email address provided during user account creation. We are experiencing a huge fake account creation attack on our public facing galaxy instance.
Does anybody who has been managing a public instance, implemented an on-demand account creation activation by sending an email containing a link, which when clicked, validate the account creation request. Or any plans from dev-team to add this in future release?
Recently, there has been increased awareness of some of the pitfalls involved in managing identity and authentication-related information in Python-based applications - not specifically to do with Python itself, but more to do with the community and the perceived best practices - and I'd really like to see a bit more collaboration around those things as well as around anti-spam mechanisms. Having looked at the authentication aspects of Galaxy, I can't help wondering if there shouldn't be some kind of generic "shell" for such functionality that is separate from the core functionality of Galaxy and would be used for other systems as well. Certainly, using Apache is one solution, but people do seem to want a more controlled kind of integration between that and the underlying applications.
At the very least, one would hope to reuse and integrate existing components, perhaps at the WSGI level. Failing that, there might be some generic libraries that could support such reusable components. Perhaps the most significant challenge would be to cleanly integrate the user interface aspects of such components with the Galaxy output.
Certainly, one could just extend the registration mechanism with captcha support, but I'd be worried about the maintainability of the code. Unless things have progressed fairly recently, there was already a lot of special-cased stuff in the area of authentication, and I'd be worried about unintentional breakage.
Paul