2011-06-02 13:09
浏览 10


Here is the current situation: I have a login page on which user enters his username and pass. Then I connect to the database using a "hardcoded" user (in the script), which opens connection to the server and executes the query to check if this data that user submitted is valid, and if so it "recognizes" him as logged in. This is the scenario that I saw and used in most of my applications.

Now, since I already have a database with many users (postgres database roles and not table "users" - I have to stress this to not mislead you) I was wondering if it would be good practice to do a pg_connect with a username and password the user puts in the login page.

My further question is how would I then keep them logged in? Session variable with username and hashed password? How is this affected from security viewpoint?

I would be grateful for your answers and any good reading material is appreciated!

图片转代码服务由CSDN问答提供 功能建议

以下是当前情况:我有一个用户输入用户名并通过的登录页面。 然后我使用“硬编码”用户(在脚本中)连接到数据库,该用户打开与服务器的连接并执行查询以检查用户提交的数据是否有效,如果是,则“识别”他登录 这是我在大多数应用程序中看到和使用的场景。

现在,因为我已经拥有一个拥有许多用户的数据库(postgres数据库角色而不是表“用户” - 我必须强调这一点不要误导你)我想知道它是否会 使用用户放入登录页面的用户名和密码进行pg_connect的好习惯。

我的进一步问题是如何让他们保持登录状态? 具有用户名和哈希密码的会话变量? 从安全角度来看,这会受到怎样的影响?


  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 邀请回答

1条回答 默认 最新

  • dongshuiga2826 2011-06-02 13:15

    I don't think that's wise at all. Technically you would have your root or admin user which can DROP or ALTER tables right? You don't want it at all possible for a user to get access to your database internals.

    Why don't you have a separate table (at the moment that is)? If you require your users to have real database access (for another system or application) then you should still create a proper users table.

    You can always write a script which will sync the data across from the internal DB users table to your application users table.

    解决 无用
    打赏 举报

相关推荐 更多相似问题