2015-09-08 2 views
0

У меня есть хранимая процедура UserLogin, вот код.MySQL хранимая процедура, странные недопустимые результаты

Параметры:

username varchar(200), user_pass varchar(200), ip varchar(50) 

Код:

BEGIN 

# find user in the database by the username and user_pass parameters 
select id_member, passwd into @user_id, @password 
from smf_forummembers 
where member_name = username and passwd = user_pass; 

if @user_id is null or @password is null THEN 
    select "mismatch" as result; 
else 
    # check the user is banned (returns a result with time) 
    set @time = IsUserBannedSMF(@user_id); 
    if @time is not null THEN 
     select "banned" as result, @time as time; 
    ELSE 
     BEGIN 
      # remove any old session 
      delete from sessions 
      where sess_usr_id = @user_id; 

      # return the data 
      select "auth" as result, @user_id as user_id, @password as pass, user_pass as pass1; 
     end; 
    end if; 
end if; 

END 

У меня есть автоматизированная тестовая программа работает, чтобы получить возможность отправлять сделать 3 задания. Это 3 веб-звонка, недействительный, действительный и тот же неверный тест, что и раньше.

Первый веб-звонок недействителен;

QUERY : CALL UserLogin('testUser1','1234','::ffff:127.0.0.1'); 
ROWS : [ { result: 'mismatch' } ] 

Второй веб-звонок, действительный;

QUERY : CALL UserLogin('testUser1','2ff4b7ec337310be7828906c6862b48f95384f9f','::ffff:127.0.0.1'); 
ROWS : [ { result: 'auth', 
    user_id: 28, 
    pass: '2ff4b7ec337310be7828906c6862b48f95384f9f', 
    pass1: '2ff4b7ec337310be7828906c6862b48f95384f9f' } ] 

Третий веб-звонок, такой же неверный тест, как один;

QUERY : CALL UserLogin('testUser1','1234','::ffff:127.0.0.1'); 
ROWS : [ { result: 'auth', 
    user_id: 28, 
    pass: '2ff4b7ec337310be7828906c6862b48f95384f9f', 
    pass1: '1234' } ] 

Третий веб-вызов должен потерпеть неудачу, как и первый веб-вызов, но возвращает действительный результат из запроса, я не понимаю, как это происходит. Есть ли в кэше MySQL вещи?

Я могу это исправить, выполнив инструкцию if, чтобы проверить пароль, но в то же время я не хочу игнорировать, почему это происходит.

ответ

1

Внести изменения как предложено ниже:

Инициализировать как вар только после того, как begin:

BEGIN 
set @user_id=null; 
set @password=null; 
# find user in the database by the username and user_pass parameters 

В случае каких-либо строк, найденных в первом select заявления, как переменные содержит ранее присвоенное значение.

+0

спасибо! Работал шармом. – Jjj

+0

@Jjj: Примите ответ. – seahawk

+0

Дополнительный анализ и объяснение этого поведения также описано на http://dba.stackexchange.com/a/35207/1165. 'SELECT INTO' не устанавливает переменную в значение null, если строки не сопоставляются, а альтернативный подход,' SET @var = (/ * скалярный подзапрос * /); 'делает. Значения сохраняются, поскольку пользовательские переменные имеют область сеанса, а не область программы. –

Смежные вопросы