2011-02-27 22 views
1

当用户登录时,他提供了他的名字和原始密码,该密码被散列并与db的值进行比较。如何在django中重复使用原始用户的密码?


def login(request): 
    username = request.POST['username'] 
    password = request.POST['password'] 
    user = auth.authenticate(username=username, password=password) 
    if user is not None and user.is_active: 
     # user is active 
     auth.login(request, user) 
     # relink to right page 
     return HttpResponseRedirect("/account/loggedin/") 
    else: 
     # error page 
     return HttpResponseRedirect("/account/invalid/") 

或者我可以只使用:


@login_required 
def index(request): 
    if request.user.is_authenticated(): 
     return render_to_response('polls/index.html', {'sessionDic' : request.session}) 
    else: 
     #some stuff 

的问题是:一旦用户登录,下面的请求包括仅进行检查和用户的Cookie也没有必要再次把他的证件。


但是,我需要查看具有原始用户的密码在每个方法登录到Linux用户和执行一些Linux程序作为该用户。对于〔实施例的su程序是用来切换ritgh Linux用户:


def ssh_command (user, password, command): 
    child = pexpect.spawn('su -l %s -c \'%s\'' % (user, command)) 
    i = child.expect([pexpect.TIMEOUT, pexpect.EOF, 'Password: ']) 
    if i == 0: # Timeout 
     print 'ERROR!' 
     print 'su can\'t be executed:' 
     print child.before, child.after 
     return None 
    if i == 1: # EOF 
     print 'ERROR' 
     print 'EOF error' 
     print child.before, child.after 
     return None 
    child.sendline(password) 
    return child 

def main(): 
    user = 'test' 
    password = 'test' 
    child = ssh_command (user, password, 'curl habrahabr.ru | wc -c') 
    child.expect(pexpect.EOF) 
    print child.before 
    print child.after 
    print child.match 

我怎么能存储原始用户的密码,并将其替换所需的功能呢?

回答

2

您可以将其存储在来自登录视图功能的会话数据中。至少它会在会议中死去。另一种选择是将其存储在数据库字段中,如果某些黑客获得了数据库访问权限,这将是非常可怕的。至少如果黑客在会话中通过密码获取数据库访问权限,他们只会获得当前会话的纯文本密码。确保适当地超时会话,或鼓励用户注销并删除会话数据。

0

您需要访问明文密码。理想情况下,您将存储该数据并重新生成哈希以进行身份​​验证。为了安全起见,您应该使用站点密码对其进行加密存储。我自己有implemented this,但不适用于Django。您将不得不重新编写Django的身份验证代码来实现此目的。

1

这是另一个想法。不要求su的密码认证。相反,使用/ etc/sudoers来允许您的Web服务器用户以其他用户的身份运行。这样你也可以限制哪些命令可以运行 - 你的当前视图是否可以防止注入到命令行?

这样你不需要保留用户密码,你只需给一个用户名(wwwuser)它需要的权限即可。 Django已经决定了用户来自哪个用户,因此我认为在给予足够的权限来执行该用户的操作时不存在问题。

相关问题