On Fri, Jul 22, 2011 at 11:08 AM, dpapathanasiou < [email protected]> wrote:
> Without getting into what's "right" or "wrong", I can explain that the > two types of users are inherently different, i.e., not inheritable > from a common base class, so user profiles and permissions will not > work, because functions in /dashboard views.py should never be > accessed (or in a position to be accessed) by functions in /console > views.py and vice versa. > This still doesn't explain what's preventing you from writing a check on each view. With the recent addition of Class-based Views to core, this would be as easy as writing two different Mixins, one in each views.py and have each function in the module subclass it. > (...) > > As for your points about site admin, I do not want two login systems; > I simply want the core login system to redirect to different paths > when it's dealing with one app's user versus another. > Redirecting User A to Path A won't prevent him from manually typing an the url to Path B and accessing the models. > I did think about your last point, i.e., writing a custom login/ > authentication routine for one app, but that defeats the purpose of > using a framework in the first place. > The good think about frameworks is that the heavy lifting has already been done for you. https://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend Cheers, AT > On Jul 22, 9:54 am, Andre Terra <[email protected]> wrote: > > No, there is no way to do that. I'm sorry, but your approach is > convoluted > > and inherently wrong. > > > > Instead of asking "how can I make this solution work?" you should be > asking > > "what's the best way to solve my needs?" and the answer to the latter > will > > be very different from what you currently have in mind. > > > > IDEAS: > > > > * There is no reason you will need two login pages. Ideally, users should > > authenticate against the system as a whole, or you will rewrite the same > > logic in many places and the code will be huge and hard to maintain. > > * Navigating through the site (and therefore accessing objects) is the > part > > that needs the permission checks. > > * Working with different models doesn't mean users have to live in two > > separate system. Again, think about permissions. Don't worry about the > > models until you get the profile permissions figured out. > > * What if an admin needs to work on both the dashboard and the console? > > Where would he login? > > * Apps should be as pluggable as possible. In that sense, have each app > > define its own urls and let the project-wide urls handle login. > > * If you really need to (and I don't see why you would), write custom > auth > > backends if you want, and restrict a user's login based on his profile's > > access level. > > > > Regards, > > AT > > > > On Fri, Jul 22, 2011 at 10:35 AM, dpapathanasiou < > > > > [email protected]> wrote: > > > Thanks for your reply, but now that I've read up on custom profile and > > > permissions, it doesn't seem like a solution. > > > > > Here's another way of explaining it: in my urls.py file, I have two > > > entries inside the urlpatterns definition, like this: > > > > > (r'^dashboard/', include('mysite.console.urls')), > > > (r'^console/', include('mysite.console.urls')), > > > > > And then inside the /dashboard/urls.py file I have this: > > > > > urlpatterns = patterns('', > > > (r'^login/$', > > > 'django.contrib.auth.views.login', > > > {'template_name': 'dashboard/login.html'}), > > > > > [etc] > > > ) > > > > > And inside /console/urls.py is this: > > > > > urlpatterns = patterns('', > > > (r'^login/$', > > > 'django.contrib.auth.views.login', > > > {'template_name': 'console/login.html'}), > > > > > [etc] > > > ) > > > > > Basically, since /console and /dashboard provide different > > > functionality to different types of users, they have different > > > templates (and their db model definitions are quite different; / > > > dashboard users are not a type of /console user, nor can they really > > > be both inherited from the same user profile class). > > > > > So, ideally, what I'd like to be able to do is something like this, to > > > force the built-in authentication to use a different url than the > > > single LOGIN_URL specified in settings.py: > > > > > urlpatterns = patterns('', > > > (r'^login/$', > > > 'django.contrib.auth.views.login', > > > {'template_name': 'dashboard/login.html', LOGIN_URL='/dashboard/ > > > accounts/'}), > > > > > [etc] > > > } > > > > > and: > > > > > urlpatterns = patterns('', > > > (r'^login/$', > > > 'django.contrib.auth.views.login', > > > {'template_name': 'console/login.html', LOGIN_URL='/console/ > > > profile/'}), > > > > > [etc] > > > } > > > > > Is there a way to do that? > > > > > On Jul 21, 9:23 pm, Andre Terra <[email protected]> wrote: > > > > Why not make custom user profiles and write permission checks on your > > > views? > > > > > > Cheers, > > > > AT > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Django users" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/django-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
