After programming a new site on my laptop (standalone web server, Django standard authentication), I moved it to the DEV server (Apache, CAS for authentication). Some things didn’t work the same.<\/p>\n
I had designed three security settings: Admin (can get to everything – superuser in Admin), Staff (can run reports, just a few permissions in Admin – marked as staff), and User (entry in Admin, but not staff and no permission, runs reports only).<\/p>\n
The views that displayed the reports use the Here’s the problem, and I saw this coming: any user who could sucessfully log in to CAS could run reports. Since I’m using a campus wide CAS database, this included any campus staff member or student. Not what I was going for.<\/p>\n I had forgotten that My solution was two-fold. Mark the User level records as staff, and replace the Next, I tried using the TIME FOR A LUNCH BREAK!!<\/strong><\/p>\n After a sandwich and a quick walk, my refreshed mind reminded me to check to see if First, I changed my import statements to grab the correct decorators for the environment.<\/p>\n (Note that This code pulls in the proper Next, for each veiw that needs protection, I implemented the decorators thusly:<\/p>\n Putting With the changes in After programming a new site on my laptop (standalone web server, Django standard authentication), I moved it to the DEV server (Apache, CAS for authentication). Some things didn’t work the same. I had designed three security settings: Admin (can get to everything – superuser in Admin), Staff (can run reports, just a few permissions in … <\/p>\n@login_required<\/code> decorator.<\/p>\ndjango_cas<\/code> adds every sucessfully loged in user as a User record in the Django Admin. At that point, the user passes the @login_required<\/code> test and can run those views. <\/p>\n@login_required <\/code>decorator with @staff_member_required<\/code>. Unfortunately, the system seemed to be using the Django internal login mechanism rather than CAS. A little code inspection showed that the decorator wasn’t using a URL redirect to login, and instead was calling the Admin login function directly. This bypasses both the django_cas<\/code> middleware and the LOGIN_URL<\/code> setting.<\/p>\n@user_passes_test decorator <\/code>testing for user.is_staff<\/code> in place of @staff_member_required<\/code> (which I will likely never use again). This also worked in the standalone setting, but not with django_cas<\/code> (kept throwing 500 errors). I then switched to the versions of the @user_passes_test<\/code> and @login_required<\/code> decorators provided with django_cas<\/code>, but then I kept getting 403 errors.<\/p>\ndjango_cas<\/code> had been updated from v2.0.2 that I had installed. Sure enough! Version 2.0.3 specifically updated the decorators. The @user_passes_test<\/code> code had been updated to return a 403 only if a logged in user failed the test, and an unauthenticated user would get a proper login screen. Furthermore, @login_required<\/code> had been removed completely and replaced with an import of the standard django supplied version. Even though I am currently unable to update the version on the DEV (or higher) servers, I saw what I needed to do.<\/p>\nimport settings\r\n\r\nif settings.USE_CAS:\r\n from django_cas.decorators import user_passes_test\r\nelse:\r\n from django.contrib.auth.decorators import user_passes_test\r\n \r\nfrom django.contrib.auth.decorators import login_required<\/pre>\n
USE_CAS<\/code> is a setting I’ve defined in the server specific settings file.) <\/p>\n@user_passes_test<\/code> decorator, and the standard @login_required<\/code> decorator, <\/p>\n@login_required \r\n@user_passes_test(lambda u: u.is_staff)\r\ndef view_staff(request):\r\n ...<\/pre>\n
@login_required<\/code> first forces a login if the user hasn’t, and then @user_passes_test<\/code> checks for the staff attribute.<\/p>\ndjango_cas v2.0.3<\/code>, the call to @login_required<\/code> will no longer be necessary. I hope to setup a project to update the version soon.<\/p>\n","protected":false},"excerpt":{"rendered":"