New authkit development branch
Etienne Robillard
Hash: SHA1
Hi,
I've started a new branch of the AuthKit library for allowing easy
integration of custom authentication and authorization backends inside
Django applications. In particular, this branch has extra enhancements
for integration with WSGI apps and the notmm toolkit. [1]
In addition, I've added in this branch a variation of the
powerpack_adaptors.py extension module, for allowing per-view
authorization using a decorator function.
To clone the branch from Mercurial:
hg clone http://joelia.gthc.org/authkit authkit-0.4.6dev
Note that I've internally named this release 0.4.6, but will wait on the
author and community approval before making a public (0.4.6) release
available. However, if you feel that the code is stable enough then
perhaps a public release would be a great thing! :)
Sincerely,
Etienne
[1]
http://gthcfoundation.org/documentation/notmm/reference/authentication.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkt6fwUACgkQ/VP9MZjcTleMoACdGv4p0YJrJ8tTz12PAny2PKdy
OX0AninVqBws8DrZyU0ux569apMlAF5r
=2SUZ
-----END PGP SIGNATURE-----
James Gardner
Your project sounds very interesting. Without looking in detail at the
code, can you give me an idea of what your code does and why exactly
it
is useful in the Django context. What is notmm for example and how
does
it fit in?
It would be quite unusual to fork a project though and then release a
subsequent version without changing the project name as people might
assume that it was an official release.
To plan the best way forward I'd like to find out a bit more about
your
plans. If you want to take responsibility for the whole codebase
(including WSGI and Pylons support) that is something probably worth
discussing on the Pylons list as there may be other people who want to
be maintainers. If you want your changes included in the AuthKit
codebase the usual approach is to write a series of tests and examples
and submit those, along with your changes so that they can be tested
by
other AuthKit developers and merged. If you really do want to fork the
project you would normally give it a completely different name and
make
it clear that your fork is not endorsed by the existing community or
authors.
What exactly was it about AuthKit that attracted you? Although AuthKit
is ideal for many purposes there are a few design decisions I'd make
differently if I was starting from scratch so I'd like to make sure
AuthKit really is a good fit your needs. A bit more detail would be
good.
Cheers,
James
On Feb 16, 11:18 am, Etienne Robillard <robillard.etie...@gmail.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I've started a new branch of the AuthKit library for allowing easy
> integration of custom authentication and authorization backends inside
> Django applications. In particular, this branch has extra enhancements
> for integration with WSGI apps and the notmm toolkit. [1]
>
> In addition, I've added in this branch a variation of the
> powerpack_adaptors.py extension module, for allowing per-view
> authorization using a decorator function.
>
> To clone the branch from Mercurial:
>
> hg clonehttp://joelia.gthc.org/authkitauthkit-0.4.6dev
>
> Note that I've internally named this release 0.4.6, but will wait on the
> author and community approval before making a public (0.4.6) release
> available. However, if you feel that the code is stable enough then
> perhaps a public release would be a great thing! :)
>
> Sincerely,
>
> Etienne
>
> [1]http://gthcfoundation.org/documentation/notmm/reference/authenticatio...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt6fwUACgkQ/VP9MZjcTleMoACdGv4p0YJrJ8tTz12PAny2PKdy
> OX0AninVqBws8DrZyU0ux569apMlAF5r
> =2SUZ
> -----END PGP SIGNATURE-----
>
> robillard_etienne.vcf
> < 1KViewDownload
Etienne Robillard
Hi James -
Glad you like the idea :)
I commented inline to your response, to ensure readability...
James Gardner wrote:
> Hi Etienne,
>
> Your project sounds very interesting. Without looking in detail at the
> code, can you give me an idea of what your code does and why exactly
> it
> is useful in the Django context. What is notmm for example and how
> does
> it fit in?
notmm is a fork/variation of the Django framework. you can use it as a
so-called "full-stack", but i don't like using this term very much..
In the scope of Django web development and WSGI, notmm can be
used to develop loosely coupled Django (WSGI) apps. For example,
developers can
combine request and response middlewares from WSGI-compatible
middlewares (like AuthKit) to develop stand-alone authentication backends.
> It would be quite unusual to fork a project though and then release a
> subsequent version without changing the project name as people might
> assume that it was an official release.
>
> To plan the best way forward I'd like to find out a bit more about
> your
> plans. If you want to take responsibility for the whole codebase
> (including WSGI and Pylons support) that is something probably worth
> discussing on the Pylons list as there may be other people who want to
> be maintainers. If you want your changes included in the AuthKit
> codebase the usual approach is to write a series of tests and examples
> and submit those, along with your changes so that they can be tested
> by
> other AuthKit developers and merged. If you really do want to fork the
> project you would normally give it a completely different name and
> make
> it clear that your fork is not endorsed by the existing community or
> authors.
I agree and I omitted developing a test case. This is on my todo list,
but of courses anyone can help out in the process of testing out this
branch of AuthKit with their current WSGI-based web framework.
Also, I don't think doing a new branch of AuthKit is required at this
time, but will let others decides what is best option for the AuthKit
project.
> What exactly was it about AuthKit that attracted you? Although AuthKit
> is ideal for many purposes there are a few design decisions I'd make
> differently if I was starting from scratch so I'd like to make sure
> AuthKit really is a good fit your needs. A bit more detail would be
> good.
Decided to opt in for AuthKit for its loosely coupled design, and
flexibility for building custom auth backends using the HTTP(S)
protocol. I also believe in Unix philosophy in what functional tools
are better (more secure) than complex and tedious authentication
protocols...
Lastly, if you want an example of a login view using the
authkit.authorize.django_adapters2.authenticate decorator, then point
your browser to the url below..
> Cheers,
>
> James
Much thanks for your input! :)
Etienne