RE: Re[2]: Sv: [phplib] occasional problem with authentication From: Chris Johnson (chris <email protected>)
Date: 05/04/01

Maxim pointed towards the behavior of ac_store() in ct_sql.inc. Perhaps
this then has a relation to the known problem in ac_store() in
ct_sql.inc in PHPLIB 7.2c. Here's my patched code at the end of that
function:

    $this->db->query($uquery);

    # FIRST test to see if any rows were affected.
    # Zero rows affected could mean either there were no matching rows
    # whatsoever, OR that the update statement did match a row but
made
    # no changes to the table data (i.e. UPDATE tbl SET col = 'x',
when
    # "col" is _already_ set to 'x') so then,
    # SECOND, query(SELECT...) on the sid to determine if the row is in
    # fact there,
    # THIRD, verify that there is at least one row present, and if there
    # is not, then
    # FOURTH, insert the row as we've determined that it does not exist.

# if ( $this->db->affected_rows() == 0
# && $this->db->query($squery)
# && $this->db->f(1) == 0
# && !$this->db->query($iquery)) {

// one line change below per discussion in PHPLIB mailing list
// regarding duplicate entries in active_sessions and a change
// to affected_rows() in MySQL 3.23 which caused this routine to fail in
// earlier versions of PHPLIB. apparently 7.2c (this version) fixes the
// affected_rows() thing but fails on the Select query. 15Feb2001, CJ.

    if ( $this->db->affected_rows() == 0
        && $this->db->query($squery)
        && $this->db->next_record() && $this->db->f(0) == 0 //
maillist fix
        && !$this->db->query($iquery)) {

        $ret = false;
    }
    return $ret;
  }

> -----Original Message-----
> From: Maxim Derkachev [mailto:max.derkachev <email protected>]
> Sent: Friday, May 04, 2001 3:14 AM
> To: Philip Strnad
> Cc: darcy w. christ; Klaus Seidenfaden; phplib
> Subject: Re[2]: Sv: [phplib] occasional problem with authentication
>
>
> Hello Philip,
>
> Friday, May 04, 2001, 9:47:17 AM, you wrote:
>
> PS> database. The interesting thing is that many times a
> user is not able
> PS> to login, even though he/she enters the correct
> username/password. I
> PS> get complaints about this every now and then. When this happens,
> PS> auth_validatelogin() ends up returning 'false'. But why?
>
> If you authenticate against a db, it could happen that a select
> query returns nothing even if it should return a row.
>
> >> debug in db_mysql.inc. What that did was show 3 debug lines. One
> >> updating the session, one selecting the session and one inserting
> >> another session.
>
> It's the CT_SQL thing (ac_store(), namely).
> It tries to update a session in the following order:
> 1: Update a session record.
> If there were no affected rows, in the case when the session does not
> exist in the db,
> or it is unchanged (which would cause affected_rows == 0 either):
> 2: Look up the session record with select.
> If nothing found:
> 3: Insert a new session record.
>
> Maybe that example of hackers' sorcery sometime cause a problem, since
> (e.g. in MySQL) update, insert and select statements have different
> priorities, and in fact could be executed in another order then they
> are passed to the db.
>
> PS> This is indeed strange, and I've noticed similar
> oddities. For example,
> PS> a user tried to login in at 09:46:24 on 1/3/01, and
> everything worked
> PS> fine. The next three entries in the log show login
> attempts for the
> PS> same exact user at the following times: 09:46:33 on
> 1/3/01 and 09:46:42
> PS> on 1/3/01. Why would a user login to the site three
> times within 18
> PS> seconds?
>
> It could be if (s)he reloads page several times after successful
> login. Login form is sent via POST, and because of that reload at the
> client is only possible by reposting the form.
>
>
> PS> I don't think anybody would actually do this, and I have
> PS> similar log entries to prove it. What this means is that
> PS> auth_validatelogin() is being called numerous times for
> some reason, and
> PS> perhaps it's related to what you saw in db_mysql.inc.
>
> auth_validatelogin() is called only after the login form is sent.
>
> It seems to me that the problem is with saving session state. Auth
> module relies on session and registers session variables during the
> authentication process. If something goes wrong with saving session
> state, it would lead to breaking authentication process (which actions
> should be performed in strict order).
>
> I had similar oddities but not with the authentication
> itself, but with
> saving session state in general. Sometimes session state has not been
> saved properly.
> I have some assumptions about the problem. I have an old computer here
> which I use for testing purposes, and I guess its slowness
> caused a MySQL to
> delay updating the session data, which turned to old session
> data being
> read at the next request. By the way, I use session4_custom.inc, which
> uses standard CT_* for custom session save handler. I decided to
> switch to 'files' module instead of db one, and everything is going
> fine since then.
> It seems to me that the problem indeed could be in CT_SQL's
> ac_store().
>
> --
> Best regards,
> Maxim Derkachev mailto:max.derkachev <email protected>
> System administrator & programmer,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: phplib-unsubscribe <email protected>
> For additional commands, e-mail: phplib-help <email protected>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>