HUE-2010 [core] Configure Hue to terminate users who has not logged in X days

Review Request #4223 — Created March 4, 2014 and submitted

abec
old-hue-rw
HUE-2010
hue
enricoberti, romain
commit 77d0c4949faa229e44c9e98f2f950e11c84ff22d
Author: Abraham Elmahrek <abraham@elmahrek.com>
Date:   Tue Mar 4 15:03:12 2014 -0800

    HUE-2010 [core] Configure Hue to terminate users who has not logged in X days
    
    Added logic to AuthenticationForm.
    Made it so that all backends return a User object even if it is inactive.
    This make it easier to see the correct error message.
    Even superuser accounts are subject to this policy.

:100644 100644 f3b6aba... 58aa316... M  desktop/conf.dist/hue.ini
:100644 100644 8132770... 4b9055f... M  desktop/conf/pseudo-distributed.ini.tmpl
:100644 100644 286ecb5... 712d794... M  desktop/core/src/desktop/auth/backend.py
:100644 100644 9901e4c... 3ccb98f... M  desktop/core/src/desktop/auth/forms.py
:100644 100644 88f6a6f... b9da19f... M  desktop/core/src/desktop/auth/views.py
:100644 100644 0c56c6c... b599c77... M  desktop/core/src/desktop/auth/views_test.py
:100644 100644 eb06e85... 3b8771f... M  desktop/core/src/desktop/conf.py
:100644 100644 2135aae... 8199d2c... M  desktop/core/src/desktop/templates/login.mako
Tested new users and existing users. Set "expires_after" to 0 and saw that after creating a user, it was immediately disabled.
Also added a test.
Loading file attachments...

  • 2
  • 0
  • 5
  • 1
  • 8
Description From Last Updated
No easy way to have a 301? romain romain
nice! romain romain
romain
  1. Nice!
    
    Just two questions: the error poping seems hacky, can't we re-use the standard form error?
    Are we ok for disabling super user too?
    1. Added a switch for disabling superusers.
  2. desktop/core/src/desktop/auth/forms.py (Diff revision 1)
     
     
    line never used?
    1. It is! In the parent class!
  3. No easy way to have a 301?
    1. Shouldn't it be 200 since the page we're accessing is the login page?
  4. this looks like a big hack
    
    could we set the error in the form and raise a validation exception? (prefered)
    
    or check user.is_active if it works
    1. We are setting the exception in the form. It looks like we just need a better representation of errors.
  5. 
      
abec
romain
  1. Ship It!
  2. 
      
romain
  1. Oups, clicked by mistake!
    
    Pretty good, just a few comments!
  2. Probably should add a:
    
    # Apply only to AllowFirstUserDjangoBackend, LdapBackend
    1. This should apply to all backends. I think the Ldap and AllowFirstUser backend required changes to get this working though. Maybe more testing for other backends?
    2. Ok, good as is so!
  3. desktop/core/src/desktop/auth/forms.py (Diff revision 2)
     
     
    Would it make sense to add a help like:
    
    Please contact an <a>admin</a> (mailto link with first admin from settings.ADMINS?)
  4. desktop/core/src/desktop/auth/forms.py (Diff revision 2)
     
     
    Account deactivated as inactive.
    
    This is simpler.
    
    Even maybe raise this message for 'inactive'
    1. How about "Account deactivated. Please contact an administrator." Provide links to the administrator as defined above.
    2. I like it!
  5. test to update after
    1. Is the user experience we're expecting here the following? If an account has been deactivated, then reactivate with a successful login? Shouldn't we have admins re-activate users? Or do you mean to test that the user is actually deactivated?
    2. I like the  "Account deactivated. Please contact an administrator." + link. The user does not need to know why I would think
  6. probably to remove as not used and not i18ned
    1. timedelta_to_string is used in auth/forms.py. 
    2. I removed it :)
  7. 
      
abec
Review request changed

Status: Closed (submitted)

Loading...