Dennis Cote <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> >Dan Kennedy <[EMAIL PROTECTED]> wrote:
> >>>
> >>The authorization callback
> >>would have to be reinvoked from within sqlite3_step() too.
> >>
> >>
> >
> >Yikes! I didn't think of that.
> >
> >
>
> I don't see why this should have any impact. If you pass the
> SQLITE_SCHEMA error back to the user, they will have to re-prepare the
> statement, which will also re-invoke the authorizer. Aren't the
> authorizer callbacks an automatic part of the compilation process? If
> the authorizer allowed you to compile the statement successfully the
> first time, isn't it almost certain that it would allow you to compile
> the statement again?
>
> Furthermore, I don't believe that most users are using an authorizer
> anyway (but I could definitely be wrong about that). In that case all
> the authorizer callbacks become no-ops don't they?
>
The authorizer is used to protect against SQL injection attaches
when the SQL text originates from user input. Typically an
application will turn the authorizer on when preparing user-supplied
SQL then turn it right back off again so that its own internal
SQL can run unfiltered. Example:
sqlite3_set_authorizer(db, ignore_passwd_column);
stmt1 = sqlite3_prepare(db, zSqlFromUser)
sqlite3_set_authorizer(db, 0);
stmt2 = sqlite3_prepare(db, zInternalSql);
sqlite3_step(stmt1); -- Oops! Might try to recompile!
Note also that the authorizer will not necessary throw an error
the first time. It might just cause certain columns in a table
to be ignored. For example, in the CVSTrac system (used for
bug tracking on SQLite as well as elsewhere) user-generated
ticket reports can query any table in the database. But if
the report requests the USER.PASSWD field, the authorizer causes
that field to return a NULL rather than the actual user password.
No error is generated so there is nothing to signal a problem
the first time the authorizer is run. But if the statement
is then recompiled automatically with the authorizer turned
off, then the PASSWD information might leak through.
--
D. Richard Hipp <[EMAIL PROTECTED]>
