django-cas - Project Hosting on Google Code

Last 30 days Dec 03, 2009 issue 8 (Invalid Ticket Handling) commented on by fahhem2 - Sorry to bother you, but can you change my credit to fahhem? That's my usual name. Thanks. Sorry to bother you, but can you change my credit to fahhem? That's my usual name. Thanks. Dec 03, 2009 NEWS (What's new in django_cas) Wiki page edited by brodie.rao Dec 03, 2009 NEWS (NEWS) Wiki page edited by brodie.rao Dec 03, 2009 NEWS Wiki page added by brodie.rao Dec 03, 2009 NEWS Wiki page deleted by brodie.rao Dec 03, 2009 issue 8 (Invalid Ticket Handling) changed by brodie.rao - Implemented in b9c4aa2b46 and released with 2.0.3. Status: Fixed Owner: brodie.rao Implemented in b9c4aa2b46 and released with 2.0.3. Status: Fixed Owner: brodie.rao Dec 03, 2009 issue 6 (Clarification: Map CAS users to staff?) changed by brodie.rao - The README and wiki homepage have been updated with some example strategies for setting superusers. Status: Fixed Owner: brodie.rao The README and wiki homepage have been updated with some example strategies for setting superusers. Status: Fixed Owner: brodie.rao Dec 03, 2009 django_cas-2.0.3.zip (django_cas-2.0.3) file uploaded by brodie.rao - Labels: Featured Type-Source OpSys-All Labels: Featured Type-Source OpSys-All Dec 03, 2009 2 new revisions pushed by brodie.rao - 0365843651:Bumped version to 2.0.3 91e036d9d9:Added tag 2.0.3 for changeset 0365843651a4 0365843651:Bumped version to 2.0.3 91e036d9d9:Added tag 2.0.3 for changeset 0365843651a4 Nov 26, 2009 issue 7 (Adding a CAS-Server to django-cas) commented on by a...@rcs4u.de - @brodie.rao: Thanks for your feedback. The patch I provided was only meant to allow django-cas to talk to another django-cas instance not as a full implementation of CAS. I made these changes and they worked for me so I tried to share. Not including them might be right choice =) @kamedov: Thanks for the pointer, I already found the project and might be using it the next time I need some SSO, it just wasn't available a year ago. @brodie.rao: Thanks for your feedback. The patch I provided was only meant to allow django-cas to talk to another django-cas instance not as a full implementation of CAS. I made these changes and they worked for me so I tried to share. Not including them might be right choice =) @kamedov: Thanks for the pointer, I already found the project and might be using it the next time I need some SSO, it just wasn't available a year ago. Nov 25, 2009 Revision de7c521352 (Changed setup.py version to 2.0.3b1) pushed by brodie.rao - Changed setup.py version to 2.0.3b1 Changed setup.py version to 2.0.3b1 Nov 25, 2009 4 new revisions pushed by brodie.rao - 62fc6147c7:Added login_required to __all__ 2602cfaf2a:Minor refactoring b9c4aa2b46:Implemented CAS_RETRY_LOGIN 6eeaa67158:Updated NEWS 62fc6147c7:Added login_required to __all__ 2602cfaf2a:Minor refactoring b9c4aa2b46:Implemented CAS_RETRY_LOGIN 6eeaa67158:Updated NEWS Nov 22, 2009 issue 7 (Adding a CAS-Server to django-cas) commented on by kamedov - Hi Arne, may be you'll be interesting in Django CAS Provider application http://github.com/Nitron/django-cas-provider Hi Arne, may be you'll be interesting in Django CAS Provider application http://github.com/Nitron/django-cas-provider Nov 16, 2009 issue 10 (db usage question) commented on by dgentry - It have a need to prepopulate the user list with my intended audience so that they can log in the first time and have the appropriate level of access. If I add them through the admin interface, I am prompted for a password. Is this the recommended way for this process, or is there another suggestion? Thanks for the great program! Dan It have a need to prepopulate the user list with my intended audience so that they can log in the first time and have the appropriate level of access. If I add them through the admin interface, I am prompted for a password. Is this the recommended way for this process, or is there another suggestion? Thanks for the great program! Dan Nov 16, 2009 2 new revisions pushed by brodie.rao - 5dce39dd48:Bumped version to 2.0.3 and updated NEWS b9a0a088bc:Added a note to the README about admin access 5dce39dd48:Bumped version to 2.0.3 and updated NEWS b9a0a088bc:Added a note to the README about admin access Nov 16, 2009 issue 7 (Adding a CAS-Server to django-cas) Status changed by brodie.rao - Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas-server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address. Status: Invalid Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas-server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address. Status: Invalid Nov 16, 2009 issue 7 (Adding a CAS-Server to django-cas) changed by brodie.rao - Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas- server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address. Status: WontFix Owner: brodie.rao Labels: Type-Enhancement −Type-Defect Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas- server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address. Status: WontFix Owner: brodie.rao Labels: Type-Enhancement −Type-Defect Nov 16, 2009 issue 10 (db usage question) changed by brodie.rao - Hi Henrik, Sorry I lost track of your ticket. django-cas creates user accounts using Django's standard User model, but passwords are never set. That's actually the very reason we use CAS: CAS receives credentials and handles authentication (confirming them with AD), thus removing the need for any Django services to handle or store credentials. You don't need to create any accounts up front; they're meant to be created as users log into your Django service through CAS. If you have many separate Django services, some services will have users that others don't. You'll also want to keep in mind that the User tables aren't pruned automatically. Only the username is populated, so you'll have to fill in the full name, email address, etc. in your own application. Status: Done Owner: brodie.rao Labels: Type-Other −Type-Defect Hi Henrik, Sorry I lost track of your ticket. django-cas creates user accounts using Django's standard User model, but passwords are never set. That's actually the very reason we use CAS: CAS receives credentials and handles authentication (confirming them with AD), thus removing the need for any Django services to handle or store credentials. You don't need to create any accounts up front; they're meant to be created as users log into your Django service through CAS. If you have many separate Django services, some services will have users that others don't. You'll also want to keep in mind that the User tables aren't pruned automatically. Only the username is populated, so you'll have to fill in the full name, email address, etc. in your own application. Status: Done Owner: brodie.rao Labels: Type-Other −Type-Defect Nov 16, 2009 Revision 375a78d849 (decorators: Only return a 403 if the user is authenticated. ...) pushed by brodie.rao - decorators: Only return a 403 if the user is authenticated. This was the original intention of the replacement decorators, which would incorrectly give 403s to users who aren't logged in. This is especially confusing when @login_required doesn't send you to the login page. decorators: Only return a 403 if the user is authenticated. This was the original intention of the replacement decorators, which would incorrectly give 403s to users who aren't logged in. This is especially confusing when @login_required doesn't send you to the login page. Earlier this year Jul 31, 2009 issue 10 (db usage question) reported by henrik.genssen - hi, is your cas server using the same DB as django? did you manage to tell cas to use the password field of a django db? or does django have its own userdb? must I copy all users from CAS-db to django-db or are they automaticly added? does every cas user have acces to django? -- Hinnack hi, is your cas server using the same DB as django? did you manage to tell cas to use the password field of a django db? or does django have its own userdb? must I copy all users from CAS-db to django-db or are they automaticly added? does every cas user have acces to django? -- Hinnack Jul 14, 2009 issue 9 (Adding Support for CAS 3 extended attributes) reported by jzylks - We are deploying a CAS 3 service, and need to support the extended attributes for serviceValidate. I've made some modifications to django_cas to accomplish this, and am attaching a diff. The major changes are: * Added a _verify_cas3 method, which returns both the username and attributes * Added a request parameter to the authenticate method, so that the additional attributes can be stored in the session To accomplish this, I modified all of the _verify methods to return a tuple, rather than a single value. That seemed like the easiest way to handle the dictionary of extra attributes from _verify_cas3, but I'm open to suggestions. We are deploying a CAS 3 service, and need to support the extended attributes for serviceValidate. I've made some modifications to django_cas to accomplish this, and am attaching a diff. The major changes are: * Added a _verify_cas3 method, which returns both the username and attributes * Added a request parameter to the authenticate method, so that the additional attributes can be stored in the session To accomplish this, I modified all of the _verify methods to return a tuple, rather than a single value. That seemed like the easiest way to handle the dictionary of extra attributes from _verify_cas3, but I'm open to suggestions. Jun 21, 2009 issue 8 (Invalid Ticket Handling) reported by fahhem2 - What steps will reproduce the problem? 1. Go to the login url (/accounts/login/ by default) and add a GET variable 'ticket' with an invalid value. /account/login/?ticket=INVALID 2. This will reply with a Forbidden page An option to 'force' authentication, as the php client has, is very desirable. This could be globally decided and/or locally decided. API changes: For local decisions, django_cas.views.login should take a new named argument 'required' and default to False. For global decisions, a new setting, possibly named CAS_RETRY_LOGIN or CAS_FORCE_LOGIN, should be in settings.py. Attached is a diff for the few lines of code to change. More work is necessary to update the documentation. Thank you for the software otherwise, really made my interaction with CAS simpler! --Farz What steps will reproduce the problem? 1. Go to the login url (/accounts/login/ by default) and add a GET variable 'ticket' with an invalid value. /account/login/?ticket=INVALID 2. This will reply with a Forbidden page An option to 'force' authentication, as the php client has, is very desirable. This could be globally decided and/or locally decided. API changes: For local decisions, django_cas.views.login should take a new named argument 'required' and default to False. For global decisions, a new setting, possibly named CAS_RETRY_LOGIN or CAS_FORCE_LOGIN, should be in settings.py. Attached is a diff for the few lines of code to change. More work is necessary to update the documentation. Thank you for the software otherwise, really made my interaction with CAS simpler! --Farz Older Dec 09, 2008 issue 7 (Adding a CAS-Server to django-cas) reported by a...@rcs4u.de - Hello, while trying to build a sso solution for multiple django-powered sites, where all sites should authenticate users against the db of a central one, I stumbled upon django-cas and looked at the CAS specs. Running a dedicated CAS server is too much overhead for my needs, so I implemented a few views and a Ticket model for django-cas which allows django-cas to act as a simple CAS 1.0 Server. Attached is a diff for you to review. I don't mind if you do not want to include this functionality because it may be out of the scope of the project, but I wanted to share the code with you. I would be happy to get some feedback. arne Hello, while trying to build a sso solution for multiple django-powered sites, where all sites should authenticate users against the db of a central one, I stumbled upon django-cas and looked at the CAS specs. Running a dedicated CAS server is too much overhead for my needs, so I implemented a few views and a Ticket model for django-cas which allows django-cas to act as a simple CAS 1.0 Server. Attached is a diff for you to review. I don't mind if you do not want to include this functionality because it may be out of the scope of the project, but I wanted to share the code with you. I would be happy to get some feedback. arne Nov 06, 2008 issue 6 (Clarification: Map CAS users to staff?) commented on by greencm - django_cas only solves the authentication issue. The authorization stuff is still the existing Users interface per normal either via the command line or admin interface. django_cas only solves the authentication issue. The authorization stuff is still the existing Users interface per normal either via the command line or admin interface. Oct 30, 2008 issue 6 (Clarification: Map CAS users to staff?) reported by rasmuskaj - The project home page says: "Users should now be able to log into your site (and staff into the administration interface) using CAS." (last paragraph in the "Installation" section). However, it doesn't mention how it is decided whether a particular CAS user is in staff. One possibility (that worked for me) is to find the User interactively and set properties on it, like this: ./manage.py shell >>> from django.contrib.auth.models import User >>> u=User.objects.get(username='foobar') >>> u.is_staff=True >>> u.is_superuser=True >>> u.save() The project home page says: "Users should now be able to log into your site (and staff into the administration interface) using CAS." (last paragraph in the "Installation" section). However, it doesn't mention how it is decided whether a particular CAS user is in staff. One possibility (that worked for me) is to find the User interactively and set properties on it, like this: ./manage.py shell >>> from django.contrib.auth.models import User >>> u=User.objects.get(username='foobar') >>> u.is_staff=True >>> u.is_superuser=True >>> u.save() Oct 07, 2008 issue 5 (Populate user data example) changed by brodie.rao - Thanks for catching that. I've fixed the project page as well as the documentation in SVN. Status: Fixed Owner: brodie.rao Thanks for catching that. I've fixed the project page as well as the documentation in SVN. Status: Fixed Owner: brodie.rao Oct 07, 2008 r34 (Fixed typo in user data example) committed by brodie.rao - Fixed typo in user data example Fixed typo in user data example Oct 03, 2008 issue 5 (Populate user data example) reported by joshua.works - Your example of populating user data on the Project Home page incorrectly says: from django_cas.backend import CASBackend where it should be from django_cas.backends import CASBackend Your example of populating user data on the Project Home page incorrectly says: from django_cas.backend import CASBackend where it should be from django_cas.backends import CASBackend Sep 22, 2008 issue 4 (No facility to add extra parameters to the login URL) changed by brodie.rao - Implemented in revision 33. Thanks for the patch. Status: Fixed Owner: brodie.rao Implemented in revision 33. Thanks for the patch. Status: Fixed Owner: brodie.rao Sep 22, 2008 r33 (Added CAS_EXTRA_LOGIN_PARAMS setting) committed by brodie.rao - Added CAS_EXTRA_LOGIN_PARAMS setting Added CAS_EXTRA_LOGIN_PARAMS setting Sep 19, 2008 r32 (Tagged 2.0.2 ) committed by brodie.rao - Tagged 2.0.2 Tagged 2.0.2 Sep 19, 2008 NEWS (Release notes) Wiki page edited by brodie.rao Sep 19, 2008 r30 (Updated version and changelog) committed by brodie.rao - Updated version and changelog Updated version and changelog Sep 18, 2008 issue 4 (No facility to add extra parameters to the login URL) reported by frasern - According to the CAS specification, in addition to the "service" parameter, the /login page on a CAS server can take the following arguments: * renew * gateway Also the CAS server I'm using takes some other non-standard arguments which allow you to customise the look-and-feel of the login form. The attached patch adds a new setting, CAS_EXTRA_LOGIN_PARAMS, which allows you to specify a dictionary of additional parameters to be used. According to the CAS specification, in addition to the "service" parameter, the /login page on a CAS server can take the following arguments: * renew * gateway Also the CAS server I'm using takes some other non-standard arguments which allow you to customise the look-and-feel of the login form. The attached patch adds a new setting, CAS_EXTRA_LOGIN_PARAMS, which allows you to specify a dictionary of additional parameters to be used. Sep 05, 2008 r29 (Fixed issues involving combining multiple login decorators b...) committed by brodie.rao - Fixed issues involving combining multiple login decorators by removing _CheckLogin usage (and removed login_required, which isn't useful to have the 403 behavior with) Fixed issues involving combining multiple login decorators by removing _CheckLogin usage (and removed login_required, which isn't useful to have the 403 behavior with) Sep 05, 2008 r28 (Added @login_required replacement) committed by brodie.rao - Added @login_required replacement Added @login_required replacement Sep 05, 2008 r27 (Removed extra whitespace) committed by brodie.rao - Removed extra whitespace Removed extra whitespace Jul 28, 2008 r26 (Removed an unused import) committed by brodie.rao - Removed an unused import Removed an unused import Jul 28, 2008 r25 (Fixed excess tab space) committed by brodie.rao - Fixed excess tab space Fixed excess tab space

issue 7 (Adding a CAS-Server to django-cas) changed by brodie.rao - Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas- server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address.

Status: WontFix

Owner: brodie.rao

Labels: Type-Enhancement −Type-Defect

Hi Arne, Sorry I didn't get back to you. I think what you have is a great idea. The official CAS server is quite a beast to configure and run; a Django implementation would be much simpler. However, I'm not sure django_cas is the best place to put this code. Right now it's just a client to the CAS server, and most users won't be using the extra server code immediately. I highly recommend that you create a separate project (django-cas- server?). If making django_cas a dependency would help, or if you'd like to take code from django_cas, feel free to help yourself. I think there's quite a bit more to CAS than what your diff implements, but it looks like a good start. If you'd like to discuss this further with me, don't hesitate to send me an email. My username here is my Gmail address.

Status: WontFix

Owner: brodie.rao

Labels: Type-Enhancement −Type-Defect

Last 30 days

Earlier this year

Older