Re: The restricted usage of auth.User model when using custom AUTH_USER_MODEL
OK, I give up. Actually I asked another question related to this topic before developing the application but the answers were similar to yours. (https://groups.google.com/forum/#!topic/django-developers/EnMn9_hU5g0) I had to use monkey-patching to allow dynamic AUTH_USER_MODEL but it wasn't a good idea so later I decided to separate the admin part and use different AUTH_USER_MODEL settings for each app. However, even separating the applications does not solve the problem because the core Django code does not assume that I can have different AUTH_USER_MODEL settings even if I use them in different server instances. Actually the customer model and staff model don't share and fields except password, last_login and created_at but since I use OneToOneField in order to map extra fields it's ok to store all common type of data in one table. I don't really like the idea of providing a regular customer user for staffs because when a staff logins into admin site, he/she also logins into the frontend site which makes harder to view the site as anonymous. Also it becomes much more difficult if I develop a feature "Login as x customer". The only useful solution that I found is to move the admin page to another subdomain (with reverse proxies like nginx) in order to prevent them to share cookies. And I also created 2 proxy models called customer and staff and modified their managers so that they can act like separate models. On Friday, February 14, 2014 12:45:16 AM UTC+2, Russell Keith-Magee wrote: > > > On Fri, Feb 14, 2014 at 1:06 AM, Burak Emre Kabakcı > <emrek...@gmail.com > > wrote: > >> I have two applications: One of them uses default auth.User model and the >> other one uses another AbstractUser class configured as AUTH_USER_MODEL. >> These two apps uses same codebase except their settings.py file. One of the >> models has a ForeignKey field in relation with auth.User model (I use >> auth.User as the staff model) and due to restriction of auth.User I'm not >> able to run the other application since I use custom AUTH_USER_MODEL. >> Django throws this error: >> >> django.core.management.base.CommandError: One or more models did not >> validate: >> model: 'staff' defines a relation with the model 'auth.User', which has >> been swapped out. Update the relation to point at settings.AUTH_USER_MODEL. >> >> I couldn't get why the usage of User model is restricted in this case. >> The only workaround I can found is monkey-patching the swappable field in >> User model's Meta field. >> > > It's not clear if this question is better suited for django-users, or if > you're asking with a view to contributing a patch to Django. For future > reference, if this is a "How can I do this" question, it's better suited to > Django-users. > > However, if you're considering options for "fixing" this: The reason the > validation code does this is to ensure that the authentication code will > work. > > At a conceptual data storage level, what you describe would be fine - > admin users are normal auth.Users, regular users are myauth.MyUser. > However, a user model isn't just used for data storage -- it's used for > authentication and login, and Django's authentication framework can only > handle one authentication model. AUTH_USER_MODEL defines which model that > will be. > > So - if the model validation code allowed for the situation you describe, > you would have an admin user model, but no admin user would ever be able to > log in. > > This isn't *necessarily* insurmountable; the auth backends tool would, in > principle, allow authentication against different data sources; we'd just > need to have a "I don't care what AUTH_USER_MODEL says, use auth.User" > ModelBackend in addition to the actual ModelBackend that Django provides > out of the box. You'd also need to make some changes to ensure that even > though AUTH_USER_MODEL has been swapped out, you still want it to be > synchronised - as currently set up, defining a value for AUTH_USER_MODEL > other than auth.User causes auth.User to not be created on disk. > > However, I'm not convinced that this would be a worthwhile set of changes. > If you go back to your original use case - why do you need two user models? > Is there any reason that this can't be done the way Django does this right > now - with a single user model that has a concept of "admin"? If 'system' > users have additional data requirements, or you want to maintain a > foreign-key level protection to ensure that admin users can't "own" data, > then add a profile model to capture the idea of a 'system' user, and keep a > foreign key between that user and the base U
The restricted usage of auth.User model when using custom AUTH_USER_MODEL
I have two applications: One of them uses default auth.User model and the other one uses another AbstractUser class configured as AUTH_USER_MODEL. These two apps uses same codebase except their settings.py file. One of the models has a ForeignKey field in relation with auth.User model (I use auth.User as the staff model) and due to restriction of auth.User I'm not able to run the other application since I use custom AUTH_USER_MODEL. Django throws this error: django.core.management.base.CommandError: One or more models did not validate: model: 'staff' defines a relation with the model 'auth.User', which has been swapped out. Update the relation to point at settings.AUTH_USER_MODEL. I couldn't get why the usage of User model is restricted in this case. The only workaround I can found is monkey-patching the swappable field in User model's Meta field. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ef3d8725-1d78-42f0-8e24-379b0d07f895%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The length of Permission.name field in django.contrib.auth module is not enough.
Hi Aymeric, Sorry for the duplication. It seems the patch is not merged for 1.6 release. Burak Emre On Saturday, November 16, 2013 8:52:18 PM UTC+2, Aymeric Augustin wrote: > > Hi Burak, > > This limitation has been known for a long time. It’s tracked here: > https://code.djangoproject.com/ticket/8162 > > Your second suggestion was implemented a few weeks ago: > https://code.djangoproject.com/ticket/18866 > > -- > Aymeric. > > > > On 16 nov. 2013, at 19:11, Burak Emre Kabakcı > <emrek...@gmail.com> > wrote: > > The name field in Permission model in django.contrib.auth module causes > problems when one of the fields' verbose_name length is larger than 39 > characters because it's maximum length is 50. ( > https://github.com/django/django/blob/master/django/contrib/auth/models.py#L63 > ) > Django automatically prepend "Can change", "Can delete" and "Can add" > words to fields' verbose names for name column when inserting rows to > auth_permission table so limits the maximum length of a verbose name to 39 > character. > When syncdb command is run, Django throws a database exception saying > "Data truncated for column 'name' at row x" in this case. I think the > length of name field is quite low but if you prefer to limit that field to > 50 character, Django should not allow verbose name attribute to be larger > than 39 character. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-develop...@googlegroups.com . > To post to this group, send email to django-d...@googlegroups.com > . > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a6266504-6339-46fb-8774-bc4254f24037%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/38a9d7c7-8595-4373-b6bd-a0d41b0dd2aa%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
The length of Permission.name field in django.contrib.auth module is not enough.
The name field in Permission model in django.contrib.auth module causes problems when one of the fields' verbose_name length is larger than 39 characters because it's maximum length is 50. (https://github.com/django/django/blob/master/django/contrib/auth/models.py#L63) Django automatically prepend "Can change", "Can delete" and "Can add" words to fields' verbose names for name column when inserting rows to auth_permission table so limits the maximum length of a verbose name to 39 character. When syncdb command is run, Django throws a database exception saying "Data truncated for column 'name' at row x" in this case. I think the length of name field is quite low but if you prefer to limit that field to 50 character, Django should not allow verbose name attribute to be larger than 39 character. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a6266504-6339-46fb-8774-bc4254f24037%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dynamic AUTH_USER_MODEL based on modules or routes
Again, thanks for the other alternatives. Today, I have worked with auth.backends.ModelBackend and it seems it would be possible to separate user resources (like if the route namespace is "myapp", then go with Customer table) if get_user(self, user_id) method is called with request parameter. It's only called by auth.get_user(request) which already has the request parameter in order to obtain backend session key. I had to change original Django source code to send extra request parameter to ModelBackend.get_user (which is really embarrassing, I know). Then I used monkey patching technique in my application code to keep Django source code original. (which is also embarrassing) The reason that I really want to do is the database will be used by another framework in Java and my teammates insist on keeping customers data on another table (It also seems reasonable to me). I think your separated project solution is the legit way to to something like that but the problem is I have to run two python instances in server and it will become harder to manage these instances. Also AFAIK they will have to use different ports I will have to use reverse proxy to attach the other project to a path. Sincerely, Burak Emre On Thursday, October 10, 2013 3:09:22 AM UTC+3, Russell Keith-Magee wrote: > > > On Thu, Oct 10, 2013 at 6:00 AM, Burak Emre Kabakcı > <emrek...@gmail.com > > wrote: > >> Thanks for the suggestions. >> >> @Andre Terra I figured out that my solution doesn't work actually. >> Custom managers is not useful in my case because underlying auth system is >> still same, it means it will also use same same session tables, cookies etc. >> >> @Russell Keith-Magee Sorry, I couldn't understand what you mean in your >> second paragraph. What I'm trying to do is exactly what you're suggesting, >> in the example there is an app called "myapp" and I resolve the url and if >> the request is routed to a view in "myapp" app I change AUTH_USER_MODEL >> setting because AFAIK all applications use a shared settings.py file. If >> there's a way to use different settings for each application, please let me >> know. >> Otherwise if you're suggesting that I should start new project that has >> its manage.py and settings.py I think it would be much more painful. >> > > Yes - I mean having two separate projects, with two separate settings > files, etc. > > As for being "more painful" -- more painful than what? You haven't > proposed an alternative that will actually work - your middleware-based > solution is fundamentally flawed, for the reasons I described in the first > paragraph of my original response. > > It's not like we're talking about a lot of code here. You need to have 2 > different settings files. However, those two settings files can share a > common base -- at a bare minimum, it only needs to say: > > --- > from common_settings import * > > AUTH_USER_MODEL = 'project1.User' > --- > > where common_settings is a file that contains the settings common between > the two projects. Yes, there's some complexity here. But then, you're the > one with a project with two different concepts of User. It doesn't matter > *what* you do, there's going to be complexity. > > It's also worth pointing out the other alternatives: > > * Use a *single* user model, but have *profiles* to cover the different > "types" of user. If you need a foreign key, use a foreign key to the > *profile*, not the User. > > * Write your own authentication backend. Django's auth backend is > pluggable, and isn't bound to auth.User at all. > > Yours > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d9b7106b-5e30-4275-ba26-112f324031c1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dynamic AUTH_USER_MODEL based on modules or routes
Thanks for the suggestions. @Andre Terra I figured out that my solution doesn't work actually. Custom managers is not useful in my case because underlying auth system is still same, it means it will also use same same session tables, cookies etc. @Russell Keith-Magee Sorry, I couldn't understand what you mean in your second paragraph. What I'm trying to do is exactly what you're suggesting, in the example there is an app called "myapp" and I resolve the url and if the request is routed to a view in "myapp" app I change AUTH_USER_MODEL setting because AFAIK all applications use a shared settings.py file. If there's a way to use different settings for each application, please let me know. Otherwise if you're suggesting that I should start new project that has its manage.py and settings.py I think it would be much more painful. Sincerely, Burak Emre -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5482e77e-effb-404b-9a70-945c5f75ee7a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Dynamic AUTH_USER_MODEL based on modules or routes
It would be nice if you allow using two different models for django.contrib.auth module. The current User model is great for admin panel users but in frontend it may become extra overhead for some cases. People try to create another user attribute models and use extra joins to be able to keep extra attributes (city, ip, locale etc.) for their users. It seems there are a lot of improvements in Django 1.5 I think there are more thing that may be revised. For example I think we should be able to set AUTH_USER_MODEL setting per module basis or namespaced routes basis. In order to solve this issue I needed to create a middleware class to change settings.AUTH_USER_MODEL; however I know that this is not the ideal solution because in each request I need to re-set one of the static Django settings. Here is the middleware class: class ChangeBaseUser(object): def process_request(self, request): match = resolve(request.path) if match.app_name == "myapp": settings.AUTH_USER_MODEL = 'myapp.Customer' else: settings.AUTH_USER_MODEL = 'auth.User' -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bd88babe-684e-4b5a-8b90-86963c40ffd5%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
