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.
Other than user models they do share data in common, which is why they all need to run on one site. 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. 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. 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.
