I was looking at the Removing The Magic wiki page, and it seems you
have no plan to remove the magic from the auth module. This came as
quite a disappointment to me. Many things in the auth module are
magical, and the auth model makes many assumptions.
The auth model can still be easy and fun to
I also suppose you could do something like, in the base class:
_name = None
_password = None
And then in the __init__ function the end user could set _name and
_password, but the get_* functions just seems simpler and more
Django-styled.
Also I haven't given any thought to the inner Admin class. I'll leave
that as an exercise to the reader, simply because I don't even really
agree with how the inner Admin class is setup.
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
> The auth model can still be easy and fun to use, and most importantly
> provide a simple means of a login system.
>
> Currently the auth model does the following:
>- Assume that we want to use columns such as "First Name" and "Last
>
Okay Adrian, I will write a patch. Should I upload it to my site and
send it through here or the bug tracker?
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
> Okay Adrian, I will write a patch. Should I upload it to my site and
> send it through here or the bug tracker?
Use the bug tracker. Here's all you need to know:
http://www.djangoproject.com/documentation/contributing/#submitting-patch
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
>
> I was looking at the Removing The Magic wiki page, and it seems you
> have no plan to remove the magic from the auth module. This came as
> quite a disappointment to me. Many things in the auth module are
> magical, and the auth model
# I think this would be cleaner if there were an authentication
# utility (just a class probably) that you could switch by changing a
# setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
I think it's also worth noting that this won't work if you ever want
to try a sequence of au
On 2/3/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
>
> # I think this would be cleaner if there were an authentication
> # utility (just a class probably) that you could switch by changing a
> # setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
>
> I think it's also worth
I'm not able to write the patch because Django is placing too many
restrictions on what I can do as far as this.
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
>
> I'm not able to write the patch because Django is placing too many
> restrictions on what I can do as far as this.
Err, simply because some people are raising concerns about the
proposed implementation? Or do you mean something to do
Writing a patch just requires too much effort. I give up and I'm
reluctantly trying to hack this together now. And it's not even fun
like the website says it is. :-(
If you are interested the problem happened when I looked at the
formfields file. I don't know how I would make that custom auth class
friendly...
And also the Admin and Meta classes.
Okay so I can probably easily do it but I'm too lazy. Also I need to
get the auth module to use our subclass of the User class and not the
original class. I'm honestly not sure how I should do this in such a
way it conforms to Django standard.
Joseph Kocherhans wrote:
On 2/3/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
# I think this would be cleaner if there were an authentication
# utility (just a class probably) that you could switch by changing a
# setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
I think
You guys are completely misintrepreting the point of this posting. It
has to do with the auth MODEL. Nothing else. When you say Model, you
are obviously referring to SQL. It is beyond me how you people come up
with LDAP and OpenID and all these other wishes.
If you want to use LDAP or OpenID, you
# If you want to use LDAP or OpenID, you obviously aren't going to use
# a Model for authentication. Especially not a Model which uses a SQL
# schema...
Actually, that all depends on how you want *external* authentication
to affect *internal* accounts. It may not be enough to say that an
OpenID
Here are my two cents,
Clearly some work will need to be done to the current authentication
system to make it more modular for those that have LDAP, OpenID, etc,
as "requirements" for there projects. Having an easy to define
authentication mechanism as Brian proposed is also very attractive. M
I, too, hope that Django gets some more modularity for authentication
(LDAP and friends). I recently blogged about how to hack in LDAP
password checking (google for the link). But I emphasize it is a "hack"
and not the official way to go about it, since it's not a complete
"swap out" of the auth m
Hi--
I was poking my head in from Plone and saw this thread. We in the
Plone community definitely want to work with other projects on shared
infrastructure. With Zope 2 doing so can be a bit of a pain, but now
that we are moving to Zope 3, code sharing should be pretty simple.
Zope 3 makes it v
Hey Geoff,
I truly believe we're at a "tipping point" (sorry-- cliched I know, but
it's true) of a time where all the wealth and experience from Zope3
will start to filter down into the other frameworks. Or at the very
least, I'll be stealing some the PAU/PAS stuff when it comes time to
"do LDAP
Great. I think it's in everybody's interest that we don't sit around
reinventing wheels.Sharing code will strengthen both projects.
It'd be great if Django could leverage the Zope community's experiences
dealing with integrating lots of authentication services with python
(and of course writi
Nevow (http://www.nevow.com/) uses twisted.cred.
24 matches
Mail list logo
