{"id":39,"date":"2009-11-21T15:55:33","date_gmt":"2009-11-21T19:55:33","guid":{"rendered":"http:\/\/dashdrum.com\/blog\/?p=39"},"modified":"2010-01-29T15:39:33","modified_gmt":"2010-01-29T19:39:33","slug":"using-cas-with-django-an-update","status":"publish","type":"post","link":"https:\/\/dashdrum.com\/blog\/2009\/11\/using-cas-with-django-an-update\/","title":{"rendered":"Using CAS with Django – an Update"},"content":{"rendered":"

As I move closer to deploying my application in production, I have been rethinking my implementation of CAS in Django, as outlined in this earlier post,Using CAS with Django<\/a>. Nothing major, but I don’t like the idea of commenting or uncommenting the code based on the server being used. Here’s what I came up with:<\/p>\n

First, I added a new variable to settings.py<\/code> called USE_CAS<\/code>. This is set to False<\/code> by default. Following that, I have some code that determines the server (out of scope for this post) and changes the variable to True<\/code> if needed.<\/p>\n

settings.py\r\n\r\nUSE_CAS = False\r\n\r\n## Check for Production server - the real code is much better than this\r\nif SERVER_ENVIRONMENT == 'Prod':\r\n    USE_CAS = True<\/pre>\n
Later, I can use that variable to decide whether to execute the CAS specific portions of code:<\/p>\n
settings.py\r\n\r\n## django_cas settings\r\n\r\nif USE_CAS:\r\n    CAS_SERVER_URL = 'https:\/\/www.example.com\/apps\/account\/cas\/' \r\n    CAS_VERSION = '2'\r\n    \r\n    AUTHENTICATION_BACKENDS = (\r\n        'django.contrib.auth.backends.ModelBackend',\r\n        'django_cas.backends.CASBackend',\r\n    )\r\n    \r\n    MIDDLEWARE_CLASSES += (\r\n        'django_cas.middleware.CASMiddleware',\r\n    )\r\n\r\n## end django_cas settings\r\n<\/pre>\n
urls.py\r\n\r\n# django_cas\r\nif settings.USE_CAS:\r\n    urlpatterns = patterns('',\r\n    url(r'^accounts\/login\/$', 'django_cas.views.login',name='login'),\r\n    url(r'^accounts\/logout\/$', 'django_cas.views.logout',name='logout'),\r\n                           ) + urlpatterns\r\n                           \r\n# end django_cas<\/pre>\n
Now, to properly direct the logout link, I’m taking a different approach.  My previous example showed how I changed the links on the top right of the page to point to the proper logout link by replacing that section of the admin template in admin\/base_site.html<\/code>.  I probably could have passed in the USE_CAS variable in the context and then selectively modified the template, but I instead wanted to simplify the process, not make it more difficult.  After searching around a little, I found an unrelated post about using redirects to handle legacy URLs.  This worked great, as I was able to redirect both the logout and change password links to the proper destination.  Note that the change password functionality is not part of my project, but is provided by the central IT organization that also provides the CAS services.<\/p>\n
urls.py\r\n\r\n# django_cas\r\nif settings.USE_CAS:\r\n    urlpatterns = patterns('',\r\n    ('^admin\/logout\/$', 'django.views.generic.simple.redirect_to', \r\n            {'url': '..\/..\/accounts\/logout'}),\r\n    ('^admin\/password_change\/$', 'django.views.generic.simple.redirect_to', \r\n            {'url': 'https:\/\/www.example.com\/apps\/account\/ChangePassword'}),\r\n    url(r'^accounts\/login\/$', 'django_cas.views.login',name='login'),\r\n    url(r'^accounts\/logout\/$', 'django_cas.views.logout',name='logout'),\r\n                           ) + urlpatterns\r\n                           \r\n# end django_cas<\/pre>\n
Pretty slick, don’t you think? Now, I have an easy to maintain setup that will work in any of my development and production environments.  Plus, I cut the number of code files affected from 3 to 2, and I have no more commenting to worry about.<\/p>\n
I would love to hear how others have solved this or a similar issue. Please leave your comments below.<\/p>\n","protected":false},"excerpt":{"rendered":"
As I move closer to deploying my application in production, I have been rethinking my implementation of CAS in Django, as outlined in this earlier post,Using CAS with Django. Nothing major, but I don’t like the idea of commenting or uncommenting the code based on the server being used. Here’s what I came up with: … <\/p>\n
Continue reading “Using CAS with Django – an Update”<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-39","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/posts\/39","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/comments?post=39"}],"version-history":[{"count":14,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/posts\/39\/revisions"}],"predecessor-version":[{"id":83,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/posts\/39\/revisions\/83"}],"wp:attachment":[{"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/media?parent=39"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/categories?post=39"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dashdrum.com\/blog\/wp-json\/wp\/v2\/tags?post=39"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}