2011-02-27 32 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已經決定了用戶來自哪個用戶,因此我認爲在給予足夠的權限來執行該用戶的操作時不存在問題。

相關問題