Re: Homogenization of User and UserProfile
I think using subclass of User model for your fields has the same flexibility as separate profile model (since you can have only one). contrib.auth can be fairly simply adjusted to use custom User model from settings instead of always using its own User. In that sense I am totally for homogenization because it will make code cleaner and eliminate unnecessary sql request not because of serialization. Such code is really an eyesore: first_name = user.first_name middle_name = user.get_profile().middle_name last_name = user.last_name > It's kind of hard to talk about "typical" Django app because there are > so many different of them :-). However what's for sure is that > significant share of Django projects consist of many apps. And those app > may store their own profile information related to users. For example > imagine some community site with a forum (an app), news comment system > (another app) and anti-spam plugin (yet another app). A forum keeps > track of users' achievements, comment system knows users' OpenID and > anti-spam have a notion of users' karma. All those things are parts of a > user profile. What do you do in such situation? Create a profile class containing all required fields? And then if you update some app you need to update your composite UserProfile model? One solution could be making each app provide its profile model, abstract model and mixin. So that you can construct whatever you want from this pieces. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Homogenization of User and UserProfile
On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > I think using subclass of User model for your fields has the same > flexibility as separate profile model (since you can have only one). You can have multiple subclasses of the User model (not that I recommend subclassing). > contrib.auth can be fairly simply adjusted to use custom User model > from settings instead of always using its own User. Yes, it could, but the entire ecosystem of reusable apps with FKs pointing to contrib.auth.models.User can't. > In that sense I am totally for homogenization because it will make > code cleaner and eliminate unnecessary sql request not because of > serialization. Subclassing doesn't solve the extra SQL request unless the base User model is turned into an abstract model, which would completely break third-party FKs. "Custom User model" is definitely a problem I'd like to see solved, but to do it in a way that's backwards-compatible and allows reusable code to point FKs at User is a difficult problem that will require adding significant new indirection capabilities to the ORM, and no-one has yet proposed a full solution AFAIK. > Such code is really an eyesore: > first_name = user.first_name > middle_name = user.get_profile().middle_name > last_name = user.last_name I agree it's ugly, but if it bothers you it's fairly easy to wrap it up into properties on your profile that proxy to the User model, and then just always use your profile (you can even add a middleware that creates a lazy-profile attribute directly on the request, if you want). > What do you do in such situation? Create a profile class containing > all required fields? And then if you update some app you need to > update your composite UserProfile model? Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction, and I'd be just as happy to see them deprecated at some point. The only justification I've heard for them is that they allow reusable code to access the user profile, but I'm not sure what reusable code is going to usefully do with a custom profile model when it has no idea what properties it has. Just use OneToOneField and the regular ORM access descriptors, and you can have as many "user profiles" as you need. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Homogenization of User and UserProfile
On Fri, Mar 18, 2011 at 2:22 PM, Carl Meyer wrote: > > > On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: >> I think using subclass of User model for your fields has the same >> flexibility as separate profile model (since you can have only one). > > You can have multiple subclasses of the User model (not that I recommend > subclassing). > >> contrib.auth can be fairly simply adjusted to use custom User model >> from settings instead of always using its own User. > > Yes, it could, but the entire ecosystem of reusable apps with FKs > pointing to contrib.auth.models.User can't. > Could one do something like this in contrib.auth.models: from django.conf import settings class BaseUser(models.Model): #same as current User model except.. class Meta: abstract = True if hasattr(settings, 'USER_MODEL'): import_model(settings.USER_MODEL) User = settings.USER_MODEL else: class User(BaseUser): pass Then foreign keys would link to the 'right' user model. There might have to be some magic with app_name.. Personally I prefer multiple profiles attached to the User model, but I can see the appeal of a unified User/UserProfile in simple projects. Cheers Tom -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Permision Denied on share acces
i got a problem that drains me. I created an application/interface that a certain thing would need to create a file on a particular share. problem is that I get IOError code 13. There are some restrictions in Django that they not know? strange is that if I make a first os.path.isdir () and returns ok, but when I try to do os.mkdir () failed suggestions? Thanks in advance -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Permision Denied on share acces
On Fri, Mar 18, 2011 at 11:57 AM, mik3langelo wrote: > i got a problem that drains me. I created an application/interface > that a certain thing would need to create a file on a particular > share. problem is that I get IOError code 13. There are some > restrictions in Django that they not know? > strange is that if I make a first os.path.isdir () and returns ok, but > when I try to do os.mkdir () failed You've sent the post to the wrong mailing list for this post. This list is for the discussion of Django development itself. Hopefully you will have better luck in general Python programming list or the django-users mailing list. Regards, -- Ramiro Morales -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Default project layout / directory structure
On 18/03/11 04:59, Alex Kamedov wrote:
> On Thu, Mar 17, 2011 at 9:26 PM, Calvin Spealman wrote:
>
>> -1 On django manipulating PYTHONPATH
>
> +1 On encouraging people to keep their applications out of their project!
>>
> I think, it's a good idea to add new option to startapp command for create
> Django application out the project and has structure compatible with
> setuptools and distutils:
That sounds handy... I'm in the process of recasting all reusable apps
here to use distutils or distribute ([1][2]) properly "manually". It's
not especially hard, but I wish they'd started out that way because we
have like 14+ of them by now. (Probably mostly never even to be
released, but to be hosted on an internal pypi-alike instance (hey
djangopypi [3]) for centralised deployment).
Aside/bikeshed:
One minor weird Python:TMTOWTDI detail I've noticed arising from the
precise names you chose for your example:
It seems to be a rule perhaps more honoured in the breach - right now,
the pypi list has a very strange mix of lowercaseruntogether, lisp-like
dashes, underscore_separated_lowercase, dot.separated.names, Even Space
Separated, CamelCase,..., - but there does seem to be a current
recommendation that the distribution/project names ("Django") themselves
as distinct from python package names ("django") should be CamelCase [4].
The "django-" prefix in the name of reusable django app distributions
has already emerged as quite widely (but not universally) used, too, and
is obviously lisp-like-dashes not CamelCase, but really I'm not clear
that it's necessary for django apps to have django- in the distribution
name, they'd presumably be categorised Framework::Django anyway if
logged on PyPI. [5]
[1]
http://guide.python-distribute.org/introduction.html#current-state-of-packaging
[2] http://packages.python.org/distribute/
[3] http://pypi.python.org/pypi/djangopypi/
[4]
http://guide.python-distribute.org/creation.html#basics-creating-and-distributing-distributions
[5] http://pypi.python.org/pypi?:action=browse&show=all&c=523
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: QuerySet subclass based on namedtuple()
I implemented it in a gist https://gist.github.com/876324 -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
CsrfViewMiddleware and HTTPS
If you're using HTTPS, the CsrfViewMiddleware performs a same_origin check on the domain. Two questions: 1. What security issue does this prevent? (I assume some kind of MITM, but I don't understand why would be important for HTTPS and not for HTTP.) 2. Because the check uses request.get_host(), and get_host() honors the X-Forwarded-Host header, isn't it possible to effectively thwart the check by sending a bogus X-Forwarded-Host header as part of evil requests? Thanks, Dave -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
what happend to #13181
did this get lost? It is accepted one year ago, but did not get in... regards Henrik -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CsrfViewMiddleware and HTTPS
This check prevents a MITM from injecting an HTTP based form/csrf token pair along with javascript to auto-submit it to an HTTPS target. Any HTTP request is vulnerable to all kinds of MITM and there's nothing we can do about it, but an HTTPS-based request should be as secure as possible even with a MITM. This protection discourages our users from building HTTP forms that post to HTTPS targets, a practice that essentially invalidates most of the browser-based security UI. SSLStrip is a very real threat. As for issue #2, of course it's possible to send anything you like as an attacker (including making up a referer header). This is about protecting non-malicious users. A malicious MITM shouldn't be able to modify an SSL request on the wire to change that header, since everything except the destination IP address is encrypted. There has been previous discussion of this issue: http://groups.google.com/group/django-developers/browse_thread/thread/d16647e84d2b39ea http://groups.google.com/group/django-developers/browse_thread/thread/22058adaf11e3ed6 and it is commented on in the code: http://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py#L139 -Paul -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CsrfViewMiddleware and HTTPS
Ah; now that I understand the purpose of the check, it all makes sense to me. Thanks, Paul! -Dave -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Homogenization of User and UserProfile
On 18 мар, 21:22, Carl Meyer wrote: > On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > > > I think using subclass of User model for your fields has the same > > flexibility as separate profile model (since you can have only one). > > You can have multiple subclasses of the User model (not that I recommend > subclassing). > > > contrib.auth can be fairly simply adjusted to use custom User model > > from settings instead of always using its own User. > > Yes, it could, but the entire ecosystem of reusable apps with FKs > pointing to contrib.auth.models.User can't. > > > In that sense I am totally for homogenization because it will make > > code cleaner and eliminate unnecessary sql request not because of > > serialization. > > Subclassing doesn't solve the extra SQL request unless the base User > model is turned into an abstract model, which would completely break > third-party FKs. I meaned making User model abstract the same way Tom Evans demonstrated. It can be still used with profiles. > I agree it's ugly, but if it bothers you it's fairly easy to wrap it up > into properties on your profile that proxy to the User model, and then > just always use your profile (you can even add a middleware that creates > a lazy-profile attribute directly on the request, if you want). One should fix problem not hide it. > Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned > they bring almost nothing to the table except for the "there can be only > one" restriction, and I'd be just as happy to see them deprecated at > some point. The only justification I've heard for them is that they > allow reusable code to access the user profile, but I'm not sure what > reusable code is going to usefully do with a custom profile model when > it has no idea what properties it has. > > Just use OneToOneField and the regular ORM access descriptors, and you > can have as many "user profiles" as you need. I always construct single profile model for a project with fields needed by all its apps. That's why I make my reusable apps provide mixins and abstracts of profiles. I think profile model is redundant itself, more of them even worse. It complicates code in many ways, constructing a form for registration and edit profile is a good example. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: what happend to #13181
On Sat, Mar 19, 2011 at 4:41 AM, Henrik Genssen wrote: > did this get lost? > It is accepted one year ago, but did not get in... Yes, it has been accepted. That means that someone (in this case, me) acknowledged that the problem described is real and worth addressing. However, the ticket hasn't been committed because it's not in the "Ready for Checkin" state. In order for this to happen, it needs to be reviewed by someone (anyone other than the original author). If you're enthused about this issue, review the patch, and if you think that it's good, mark the ticket ready for checkin. We've just recently added some new docs to help clarify our contribution process -- have a read and see what you can do to help Django become better: http://docs.djangoproject.com/en/dev/howto/contribute/ Nothing happens to any ticket unless the community gets involved -- that means you! :-) Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Homogenization of User and UserProfile
On 03/18/2011 07:22 AM, Carl Meyer wrote: Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction +1 Just use OneToOneField and the regular ORM access descriptors, and you can have as many "user profiles" as you need. True. Long ago I've coded a custom AutoOneToOneField[1] that implicitly creates a dependent profile object on first access. It turned out to be useful in many cases. [1]: http://bazaar.launchpad.net/~isagalaev/+junk/cicero/view/head:/fields.py#L19 -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
