QuerySet.__or__ bug?
I think I've found a bug when doing | (__or__) on QuerySets when or'ing with a QuerySet that filtered on a ManyToManyField. For example: The Model (Ticket): shortdesc = models.CharField(maxlength=255) desc = models.TextField() users = models.ManyToManyField(django.contrib.auth.models.User) There's only one Ticket at the moment: shortdesc = 'boo' desc = 'this has to do with linux' users = [spr, peter] Then in the python shell (started with 'python manage.py shell') I do: >>> from tick.tickets.models import Ticket >>> s = Ticket.objects.filter(shortdesc__icontains='boo') >>> o = Ticket.objects.filter(users__username='boo') >>> s [] >>> o [] >>> s | o [, ] >>> p = Ticket.objects.filter(desc__icontains='linux') >>> p [] >>> p | o [, ] >>> This doesn't seem to be correct or behavior, based on what I'm seeing in the code. Is there something special I need to do when dealing with a ManyToMany, or is this a bug? Thanks, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Tue, Aug 01, 2006 at 07:58:10PM +0200, [EMAIL PROTECTED] wrote: > I read a lot about django's auth system and the AUTHENTICATION_BACKENDS > middelware. I also googled the following resources for LDAP support in django: > > http://code.djangoproject.com/wiki/MultipleAuthBackends > http://www.jrandolph.com/blog/?p=22 > http://www.carthage.edu/webdev/?p=12 > > Are these solutions sufficent for most of you ? > Is somebody working on a general solution, which maybe makes it into > django.contrib.auth.ldap ? > Has somebody experiences with LDAP/django performance impact ? > > As I came over the django from Zope I know the LDAPUserFolder [1] there, with > feature rich mappings from LDAP-Groups to Zope-Roles, LDAP-attribute mapping > and LDAP-caching. > > I made the LDAPUserFolder to work with django. But this seems a little > oversized. > > Regards, > Dirk > > [1] LDAPUserFolder: http://www.dataflake.org/software/ldapuserfolder > I'm actually doing LDAP auth with something I wrote myself, which I feel is a little more general than the mentioned code (not that I'm opinionated or anything). I'll be posting it in a day or so once it's cleaned up a bit more. During OSCON I mentioned to Adrian that I'd be willing to work on one that would make it into django. LDAP is working great for me but we're not the highest demand environment, though I'd expect that LDAP auth will scale as well as LDAP can. Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Tue, Aug 01, 2006 at 12:08:25PM -0700, Scott Paul Robertson wrote: > I'm actually doing LDAP auth with something I wrote myself, which I feel > is a little more general than the mentioned code (not that I'm > opinionated or anything). I'll be posting it in a day or so once it's > cleaned up a bit more. During OSCON I mentioned to Adrian that I'd be > willing to work on one that would make it into django. > I've finished the code for a backend that works with LDAP. It pulls all the needed variables from your settings.py file, and covers everything that I could think of. I don't have an ssl based ldap server to test with, but I think if you want ssl you only have to have the uri be ldaps:// instead of ldap://. I've submitted it as a patch to trac: http://code.djangoproject.com/ticket/2507/ Scathing comments are encouraged. -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Wed, Aug 09, 2006 at 08:00:31PM -0700, Gary Wilson wrote: > > Scathing comments are encouraged. > > line 68 of patch: > if not username and password is not Null: # we need a user/pass > Should be None d'oh! Figures I'd mistype something like that. > And how about moving the ldap.initialize() call after the above check > so that we don't make an unneeded connection to the ldap server. You know it was on my list, and I missed it when I was going through my cleanup today. Thanks. > Also, in the ldap setup I deal with, you must bind to the server using > a service account before attempting a bind with the user-supplied > credentials. The process goes something like > > 1. Retrieve the username and password from the user. > 2. Bind to the directory using DN and password of service account. > 3. Issue a search query to determine the user's DN based on their > username. > 4. Attempt to bind to the directory using the user's DN retrieved in > step 3 and the password supplied by the user in step 1.. > 5. A successful bind means that the user has been authenticated. An > unsuccessful bind means that the credentials provided are invalid. > > This also seems to be the method used/needed in the second resource > link you listed in your first post. It would be great if this method > could be supported. It would require a few more options like > LDAP_SERVICE_BIND_DN > LDAP_SERVICE_BIND_PASSWORD > and then an additional check in authenticate() (after the call to > initialize() and before the bind with the user's DN and password) to > see if first a bind should be attempted with the service account DN and > password. > I'll start on this tomorrow. Out of curiosity how common is this sort of setup? I've only seen a handful of LDAP implementations, and this is new to me. Thanks for the comments, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpTklkBRjQxO.pgp Description: PGP signature
Re: django and LDAP support
On Wed, Aug 09, 2006 at 10:22:24PM -0600, Scott Paul Robertson wrote: > > Also, in the ldap setup I deal with, you must bind to the server using > > a service account before attempting a bind with the user-supplied > > credentials. The process goes something like > > > > 1. Retrieve the username and password from the user. > > 2. Bind to the directory using DN and password of service account. > > 3. Issue a search query to determine the user's DN based on their > > username. > > 4. Attempt to bind to the directory using the user's DN retrieved in > > step 3 and the password supplied by the user in step 1.. > > 5. A successful bind means that the user has been authenticated. An > > unsuccessful bind means that the credentials provided are invalid. > > > > This also seems to be the method used/needed in the second resource > > link you listed in your first post. It would be great if this method > > could be supported. It would require a few more options like > > LDAP_SERVICE_BIND_DN > > LDAP_SERVICE_BIND_PASSWORD > > and then an additional check in authenticate() (after the call to > > initialize() and before the bind with the user's DN and password) to > > see if first a bind should be attempted with the service account DN and > > password. > > > > I'll start on this tomorrow. Out of curiosity how common is this sort of > setup? I've only seen a handful of LDAP implementations, and this is new > to me. > Ok, I've added a patch that adds two new things: 1. You can have a hash of ldap options (key: ldap.SOME_OPTION, value: 'the value') that will be applied before the initialize call. 2. An option that is a function that will be called to generate a bind string for the user. This gives a lot of flexibility in allowing for a large variety of pre-bind methods to occur, and gives a lot of flexibility. I like the idea of adding this rather than an additional method to be added into the main backend code. Let me know what you think of having that as a function you call rather than being directly in the backend. I'm not against adding it in, I just think this gives a lot more flexibility. Heck, we could add the method of pre-auth binding as a default method provided by the backend and just have users set the option to that if they want to use it. I actually like that idea, I might code that up this afternoon. :) (url: http://code.djangoproject.com/attachment/ticket/2507/backends.py.2.diff) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Thu, Aug 10, 2006 at 12:41:21PM -0600, Scott Paul Robertson wrote: > 2. An option that is a function that will be called to generate a bind > string for the user. This gives a lot of flexibility in allowing for a > large variety of pre-bind methods to occur, and gives a lot of > flexibility. I like the idea of adding this rather than an additional > method to be added into the main backend code. > > Let me know what you think of having that as a function you call rather > than being directly in the backend. I'm not against adding it in, I just > think this gives a lot more flexibility. Heck, we could add the method > of pre-auth binding as a default method provided by the backend and just > have users set the option to that if they want to use it. I actually > like that idea, I might code that up this afternoon. :) > Ok, I've added a newer patch that fixes a small bug (the bind string functions now expects the ldap object and the username), and added a method that performs the pre-auth as requested, with an example of how to use it. So now we've got that functionality, and any additional ways to generate bind strings that you can dream of. I'm enjoying this far too much. I need to get back to work :) Scott (url: http://code.djangoproject.com/attachment/ticket/2507/backends.py.3.diff) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
Ok, one last change to make it more 'pythonic'. Just a slight change to make using the pre-auth bind function easier. I think this finishes out the patch. If there are any other ideas or suggestions, please let me know. Scott (http://code.djangoproject.com/ticket/2507/) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Fri, Aug 11, 2006 at 07:46:19PM +0200, [EMAIL PROTECTED] wrote: > I came back to your LDAPSupport. The pre_auth_bind is a little bit tricky > evan with mk_pre_auth_bind, but I got it (after a while :) > Ok, I've done some cleaning with mk_pre_auth_bind. It should be a lot clearer how to use it, and easier. > And there seems a problem with pre_auth_bind() and update_user(): > > You let construct somebody a pre_auth_bind() which search for the dn of a > user, but on the other side you construct in update_user() always your own > search. > > If pre_auth_bind() returns a valid user-dn, this would be the same dn for > updating the user object. > > I would asume that update_user() call the ldap-object by the dn directly (if > a user-object as a dn-attribute, which needs to be stored!) or if the > user-object is new the update_user() should use the same search which is done > in the custom pre_auth_bind(). > I would love to not have to do two searches. Unfortunately the only way in ldap to get attributes is by a search, even if you have the dn already. I could require an LDAP_BIND_STRING_FUNC to return a bind string and a hash of attributes, but that reduces flexibility in my opinion. If the person generates a bind string without interfacing to ldap, I shouldn't expect them to produce a list of attributes and values for me. I've made it so you specify a setting LDAP_SEARCH_FILTER that is used to search, so previous where the search would be: '%s=%s' % settings.LDAP_BIND_ATTR, username it is now: filter = settings.LDAP_SEARCH_FILTER % username This allows the search filter to be the same in update_user() and the pre_auth_bind(). By setting some default values for mk_pre_auth_bind() it should be easy to use: LDAP_BIND_STRING_FUNC = mk_pre_auth_bind('dn=Me,dc=example,dc=com, 'pass') which defaults to: LDAP_BIND_STRING_FUNC = mk_pre_auth_bind('dn=Me,dc=example,dc=com, 'pass', LDAP_SEARCHDN, LDAP_SCOPE, LDAP_SEARCH_FILTER) I think that gives you the functionality you want, and makes it a lot easier in general. I've submitted the updated patch. Let me know if there's anything else, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Sat, Aug 12, 2006 at 10:09:28AM +0200, [EMAIL PROTECTED] wrote: > for sure I understand now why you need a second search on update_user() and > with the defaults for mk_pre_auth_bind those two searches should be the same. > > A security question about get_ldap_user() > > def get_ldap_user(l, username): > """ > Helper method, makes a user object and call update_user to populate > """ > > user = User(username=username, password='Made by LDAP') > LDAPBackend.update_user(l, user) > return user > > Is setting password to 'Made by LDAP' opening a backdoor ? > If somebody accidently remove the LDAP-Support or uses both DB and LDAP, can > this open a security hole ? > > I would prever to use a random choose password. > That is a good point, if you have both backends working, this would present a problem. I'll go ahead and have it generate a random password in there instead. Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpEw6dDODQuN.pgp Description: PGP signature
Re: multiple authentication and session keys
On Thu, Aug 03, 2006 at 10:42:39PM -0700, Gary Wilson wrote: > > So, the mutli authentication seems to work well for the use case of a > site accepting more than one authentication source to access some area, > but not so well for the use case of a site accepting one source of > authentication in one area and another source of authentication in a > different area. > > The contrib.auth.login function currently writes the user's id to > session['_auth_user_id'] and the backend to > session['_auth_user_backend']. When using more than one authentication > backend, the session data gets stomped on. I propose that the session > data be keyed by backend somehow so that authentication session data is > kept separate. > > The login function would change to key the session data by backend. > The logout function would log the user out of all backends, or > optionally take in a backend to log the user out of only that > particular backend. The get_user function with no parameters would > return the first user object it finds calling backend.get_user() for > each backend in AUTHENTICATION_BACKENDS in order, or optionally take a > backend to try and get the user from. > You also run into a problem if you change the authentication backends and don't clear out your cookie. Django will fail trying to authenticate with a now non-existent backend. I can grab the traceback if it's needed. -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgph5rypM2Kb2.pgp Description: PGP signature
Re: django and LDAP support
On Sat, Aug 12, 2006 at 10:11:53PM -0700, Gary Wilson wrote: > You can remove the l.unbind_s() on line 77. :) Thanks again. > > It would also be great if the authenticate() method wasn't tied to the > contrib.auth.models.User model. I, for one, use my own custom user > model. Maybe extracting the parts that try to get and update the user > in authenticate() could be extracted to another method so that people > using a custom user model could easily override these methods. > > Maybe the LDAP_BIND_STRING_FUNC should be moved to a class method > instead, which would be empty by default? Then you could just inherit > LDAPBackend and override this pre_bind() method if you wanted to do > something special (like bind with a service account first). This > pre_bind() could be called after intialize() and be passed the ldap > object and username, just as LDAP_BIND_STRING_FUNC. > I've been thinking about how to decouple from contrib.auth.models.User, and I think having people inherit and override is the best method. With that change the LDAP_BIND_STRING_FUNC would be changed as suggested. I'll probably have a patch up tonight changing this. One question: should I leave in the provided mk_pre_auth_bind() function? If I did you could override the pre_bind function simply by: pre_bind = mk_pre_auth_bind('username', 'pass') It sounds like there are enough people looking for the feature so I think leaving it in is a benefit. Anyhow, let me know if you have any thoughts, and I'll have the patch in tonight. Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: django and LDAP support
On Mon, Aug 14, 2006 at 12:51:47PM -0600, Scott Paul Robertson wrote: > Anyhow, let me know if you have any thoughts, and I'll have the patch in > tonight. > Patch is in place. I'm aware of a trailing sentence in the doc string and a typo with get_user() in the doc string as well, but won't worry about that till it's be checked and tested. So now if you want to change the model for the user you simply: class MyBackend(LDAPBackend): def _get_user_by_name(self, username): return Model.objects.get(username=username) def _create_user_object(self, username, password): return Model(username, password) def get_user(self, userid): try: return Model.objects.get(pk=userid) except: return None And you can change the generation of the bind string like so: class MyBackend(LDAPBackend): _pre_bind = LDAPBackend.mk_pre_auth_bind('user', 'pass') It seems pretty clean to me, and allows for more flexibility. Let me know what all of you think, and if there is anything else that should change. Scott (http://code.djangoproject.com/ticket/2507) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpAinNrT2ksA.pgp Description: PGP signature
Re: django and LDAP support
I've been running the patch in production for the past few days, and done quite a bit of testing. The basic setup works just fine. If mk_pre_auth_bind() is going to stay in, I'd like to hear back from someone who's tested using it to know if it is working. I'm pretty confident it is working correctly though. Is there anything else? Otherwise I feel pretty good about the patch, and think it's ready for general use. Is there anything that would keep it from being added to trunk? I'll be without 'net access for the weekend, so I'd love to hear any other suggestions tomorrow if at all possible. If not I'll just work on it on Monday. Thanks, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpO3XATbjWs8.pgp Description: PGP signature
Re: Proposal: Forms and BoundForms
On Tue, Sep 12, 2006 at 02:35:54PM -0500, Adrian Holovaty wrote: > Let's change this to be similar to model classes, like so: > > class ContactForm(Form): > sendername = TextField() > senderemail = EmailField() > subject = TextField(maxlength=20, blank=True) > message = TextField() > I've got two thoughts that I'd like to see. Inter-field dependency. For example: class AdminTicketForm(Form): ... state = SelectField() solution = TextField(blank=True) related_to = SelectField(blank=True) field = TextField(blank=True) depends_on_field = TextField(blank=True) Now in this case I actually want to say that is state equals 'resolved' then solution needs to be filled and if state equals 'duplicate' then related_to needs to be filled. That's an actual case I have in my app. The field 'field' is just there as an example of the general case: if field is not blank then neither should depends_on_field. Putting this in the class seems natural, so maybe something like: state = SelectField() solution = TextField(blankunless='state == resolved') related_to = SelectField(blankunless='state == duplicate') field = TextField(blank=True) depends_on_field = TextField(blankunless='field') Is this something that is worthwhile? It would be really useful for me, and I bet other people would like it too. The syntax isn't quite right I think, but that can always be improved. The other thing has to do with hidden fields in Forms. Typically if people want to have a field passed through, but not editable, you set it as hidden. Of course hidden values can be edited by the enterprising user. Basically maintaining the 'follow' attribute of ChangeManipulators, and making sure that I can put values back in easily to the BoundForm (or whatever it's called). Not too worried about this going away, but just want to make sure. Otherwise I really like the proposal so far, and I'll chime in and give a +1 to having just Form and not Form and BoundForm. Thanks -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpmSzKO0tQ34.pgp Description: PGP signature
Re: Re: Proposal: Forms and BoundForms
On Fri, Sep 15, 2006 at 09:25:37PM -0500, James Bennett wrote: > > On 9/15/06, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > > Inter-field dependency. For example: > > Most of this looks like it can be much more flexibly handled by the > already-available validator syntax (which, I assume, will be finishing > its migration into the model system). > Ah, I wasn't aware that the validator system would be moving into models. Must have missed that. That's even better :) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpgZe9XDajY6.pgp Description: PGP signature
Re: Newforms: seperating database and form logic
On Fri, Nov 17, 2006 at 12:00:02AM -0600, Adrian Holovaty wrote: > However, one goal I've had for newforms *is* to let developers > manually specify/override the form Field used for any particular > database Field in the admin site. I think this could be achieved with > a hook in the "class Admin". Something like this, maybe -- > > class Admin: > field_overrides = { > 'first_name': CharField(widget=PasswordInput), > } > This would affect how the fields display when you auto-generate a form from a model as well, right? Should that go in somewhere more general than the Admin class? -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpoklEwM93Nu.pgp Description: PGP signature
Re: django.contrib.formtools: High-level abstractions of common form tasks
On Mon, Dec 11, 2006 at 11:52:19AM -0800, Kevin wrote: > I'm mainly concerned with the scenario where credit cards are used as > part of the form. I haven't found too many supported cryptography > libraries for python though. > As far as crypto libraries go, I've used the Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto) a number of times, and have been pretty pleased with it. Thought you might like to know. -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpWBB5zmTwv1.pgp Description: PGP signature
Re: Proposal: Named auth backends and backend specific profiles
On Wed, Jan 10, 2007 at 01:10:03PM -0600, Joseph Kocherhans wrote: > > 1. Named auth backends > > Right now, user logins are coupled to the actual location of an auth > backend. The python dotted path of the backend is stored in the user's > session when they login. If you were to move the backend to a > different module, any user who was logged in via that backend would > get a 500 the next time they tried to view a page because the class > corresponding to the dotted path in their session would no longer > exist. I propose to register and lookup backends by name to fix this > problem. Here's a configuration sample: > > # a tuple of (name, path) tuples > AUTHENTICATION_BACKENDS = ( > ('default', 'django.contrib.auth.backends.ModelBackend'), > ('ldap', 'mypkg.backends.LDAPBackend'), > ) > > This will allow you to change to a different backend class, or move it > to a different module or package without breaking your existing logins > since they will be looked up by name rather than by path. This is a problem I've run into myself, when I switched from having my LDAP backend in my app, to running it as a patch (#2507). Currently I'm assigning the new backend the old one's name so old session cookies still work. In other words, +1 on this. > > 2. Link users to their backends > > Adding a 'backend_name' field to django.contrib.auth.models.User would > allow us to tie a user object to a specific backend when it is > created. This would be a choice field with the choices populated from > AUTHENTICATION_BACKENDS. It would allow us to use default django users > and look them up by the type of backend they are tied to. (i.e. give > me all OpenID users, give me all ldap users, etc.) This depends on > point one, and makes the next proposal possible. > +1. The LDAPBackend in trac currently makes a User object when a user first authenticates, and provides a random default password. This is so if someone tries to authenticate and fails and the next backend is the Model backend, the person can't login with a static default password. It would be nice to not have to worry about that. > > 3. Store backend specific user profiles > > I also propose to extend the AUTH_PROFILE_MODULES pattern to support > backend specific profiles. This would depend on both of the previous > points. Here's a configuration example: > > BACKEND_PROFILE_MODULES = { > 'ldap': 'mypkg.models.LDAPProfile', > } > > And to get the backend specific profile for a user: > > user.get_backend_profile() > > get_backend_profile() would user user.backend_name and > BACKEND_PROFILE_MODULES to return the appropriate profile model. > +1 > > 4. Dealing with username > > Things like OpenID don't require a username, but the default > django.contrib.auth User model does. We could hack something together > in an OpenID backend to make up a unique username, but that seems kind > of silly since we just don't need it. To fix this, the required=True > attribute of the username field should be removed and a custom > validator should take it's place. This validator should look at the > new user.backend_name field to determine if the *backend* requires a > username field. If backend_name is not available in the validators > all_data argument, the validator will assume that username is > required. My initial thinking is that an attribute named > username_required or something similar could be checked on the backend > object. To indicate that username is *not* required, you'd just set > that attribute on your backend class. For instance: > > class OpenIDBackend(object): > username_required = False > > def authenticate(request=None): > # validate the openid server response and return a user > +1 -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpMe4PdWopg4.pgp Description: PGP signature
Re: Proposal: Named auth backends and backend specific profiles
On Tue, Jan 16, 2007 at 09:49:51AM -, PoBK wrote: > I'm not certain how anyone else feels about this, but personally, I > hate the fact that I have to have a DB for authorization if using the > contributed auth module. AAA should be one entity since it breaks the > whole loosely decoupled DRY principle. If you use a proper LDAP server > (and I'm probably going to get flamed to hell with this) then > Authentication and Authorization are already builtin. There's just no > need to repeat yourself writing an ACL system. > > I've got Django happily authenticating with eDirectory and applying the > rules, ACLs and policies stored in eDir to elements in my Django > applicaiton. Granted, it was a royal pain in the arse and the code is > embarrassingly messy, but it does work. Django is true middleware in > the sense that I don't have the bog it down with authorising each > request. This is done by the Directory. I have true separation of > concerns. > > There is no reason to couple Authentication and Authorization so > closely. It just doesn't make sense to me. Why can't user profiles be > stored in LDAP? That's what it is designed to do. > > Chances are, if you're using an LDAP backend, you want to apply the > same functionality the current Auth system applies to the database, to > the LDAP profile, else you get a de-synchronisation of information. > e.g. Authenticating against Active Directory and allowing webapp based > modification of user profile stored in LDAP. I use LDAP a bit differently. Using the LDAPBackend in ticket #2507 works rather well for me. When I wrote the patch, I understood that to use the current auth system means to make User objects. I for one was happy with this because I can create object relationships with User accounts and not have to query LDAP to get the information. We don't have very fine grained ACLs with our Django app, and users with special permissions are unlikely to stop being so. So copying over the information from LDAP was good enough for us. Now to get the level of integration you want, it sound like what the generic auth branch does. Have you looked into using the branch? In any case I'm interested to see what you've done and curious to see what you had to do to get it to work. -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpFfXDEXrInf.pgp Description: PGP signature
Re: newforms: proposal ModelForm Baseclass for model related Forms
On Mon, Feb 12, 2007 at 07:45:52AM -0800, RonnyPfannschmidt wrote: > > The actual method of creating Model related forms is a set of > functions returning form classes > > thats nice to use, but not very nice to extend > > Im proposing a Base class wich allows to pass models/instances to > generate forms, or inherit to extend the forms > > > default usage would be ModelForm(model=MyModel), > ModelForm(instance=myinstance) > or ModelForm(model=MyModel,object_id=myid) > > > extending would be something like > > class EntryForm(ModelForm): > Model = Entry > remove_fields=("some","private","fields") > # some fields of entry need custom formfields, so lets just set > them up > text = SaveXHTMLField(widget=TinyMCEWidget) > def clean_title(self): > pass # i should really do the check here > > > to make a AddForm i would just use EntryForm() > to get a EditForm i'd just use EntryForm(instance=e) or > EntryForm(object_id=entry_id) > I've actually been using newforms with regards to models recently. I don't think there is a need for a new class to extend. Rather, you could easily do the same in models.form_for_model with extra arguemts (which don't exist at the moment). IE: form_for_model(Entry, not_required=['some','private','fields']) Also changing widgets is a breeze: EntryForm.fields['text'].widget = some.widget.class() You can still add clean methods after the fact by assigning functions to EntryForm.clean_title, ie: EntryForm.clean_title = lambda self: pass # do stuff -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpFUDqZuIRBs.pgp Description: PGP signature
Sub-directory in django/contrib/auth for contributed auth backends.
With reference to ticket #2507, the LDAP authentication backend, being accepted there has been some discussion where to put the file. The current patch puts the backend in django/contrib/auth/contrib/ldapbackend.py. The idea is that it is a contrib to the auth framework contrib. We're looking for some input on where this should go, and I'd imagine that any other contributed auth backends will go in the same location (OpenID comes to mind). So should additional auth backends go in django/contrib/auth/contrib, django/contrib/auth, or some place entirely different? Thanks, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgp2X7WN1R2Xg.pgp Description: PGP signature
Subdirectories for documentation?
This came up in discussion of the LDAP Backend patch (#2507). We need to document the backend, but there isn't a clear place to put the documentation. The authentication doc is already pretty long and, in my opinion, would feel rather cluttered adding documentation for using an LDAP backend (which will take a decent sum of space). I'll quote from the ticket: "The documentation issue is that djangoproject.com has no way to provide subdirectories (in this case /authentication/contributed/) which would place docs for this in an ugly url (/contributed_authenticators/ and /ldap_autenticator/), my idea was to create a new doc (/authentication/contributed/ or /contributed_authenticators/) to explain small contribued authenticators and link bigger ones like (/authentication/contributed/ldap/ or /ldap_authenticator/) just to be ready in case more authenticators get contributed. As you see URLs are far more clean with some directory depth support so I've left the docs where they are until we get this discussed ;)" So what's the best place to put docs for things like bundled auth backends? I imagine that there are a lot of un-documented parts of Django that would make sense to have their own page that is a child to another primary page. Thanks, Scott -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 pgpggYe5mCach.pgp Description: PGP signature
wiki coordinator position
So I've been tossing this idea around in my head for a while now, and wanted to see what everyone thought of the idea. Basically I think the wiki could use someone to work on it as something akin to an editor. Jacob put it well when I mentioned this to him yesterday, that the wiki could use a "gardener". Someone to keep the various branch and status pages up to date with the dev list, keep an eye out for spam, and work on generally cleaning things up. Some reasons I think this would be a good idea: 1. For the person who doesn't follow the dev list, finding out the status of major branches is hard - having someone other than the developer keep the status updated benefits everybody. 2. Cleaning up the wiki (especially the front page and the development related pages) would help new people to more easily become contributors. 3. Having a designated person to pester developers about the status of branches wouldn't hurt. This person wouldn't be writing content necessarily, but would work on keeping things neat. So what does everyone think? Is this a worthwhile idea? Since I'm throwing out the idea, I'm willing to do this. Is any one else interested? Scott --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: wiki coordinator position
On Tue, Jul 24, 2007 at 06:52:54PM -0500, Adrian Holovaty wrote: > > On 7/24/07, Scott Paul Robertson <[EMAIL PROTECTED]> wrote: > > [ Discusion about editor for development wiki pages... ] > > Since I'm throwing out the idea, I'm willing to do this. Is any one else > > interested? > > This would be fantastic. It gets a big +1 from me. > So someone out there may be asking, "What happened with this?" Answer: I have dropped off the face of the planet. Status: I'm not coming back anytime soon. I'm really bummed by this, I really was looking forward to helping out. Life reared its ugly head and I'm not in a position to trim the wiki and edit pages. I thought I should let people know. It would really keen if someone else picked this up, I still think the Django wiki could benefit from a light hand keeping things orderly. In the spirit of the day (what there is left of it): "Avast ye sea dogs, will one of ye take the plung to help the wiki?" :) -- Scott Paul Robertson http://scottr.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---