authentication

kante

In a normal login system where user inputs username and password,
post vars, check them in a db table, and the redirect to the restricted area,

where a session starts and some data are registered to keep track of the user, and check if authorized:

how many session vars better to register? to avoid people from tryin to enter without authorization?

for example is it sufficient to register username plus his id in the authUsersTable
so i can perform the auth check by a SQL query where both the couples match?

bradgrafelman

kante wrote:
how many session vars better to register? to avoid people from tryin to enter without authorization?

for example is it sufficient to register username plus his id in the authUsersTable
so i can perform the auth check by a SQL query where both the couples match?

I would simply store the id, since it presumably won't change from one visit to another (e.g. they might be able change their username, but their user id is something tied to their account and can't change it).

Are you thinking that the user might be able to modify (or falsify) the session data? If so, that sounds like you don't know how sessions work (e.g. the session data isn't stored anywhere on the user's computer, thus it's not possible for the user to view, modify, or spoof it).

kante

yes you caught me... i thought Session works like cookies... so the user could possibly modifiy te cookie text file to access, tryin some other id randomly...

but now i miss something.... something must be stored temporarly to the user machine to keep the link on.... is it only the phpsessid string that is stored?

NogDog

The only thing exchanged is the session ID (a pseudo-random string), which normally is exchanged via a cookie. That identifies the user's session, but all the actual session data stays on the server, using the session ID to determine which set of data belongs to that user.