like и case-sensivity абсолютно никак не связаны. case-sensivity задается при создании таблицы. если у вас collation выставлен c case-sensitive, то like будет учитывать регистр так же как и = . если колонка создана case-insensitive , то опять же поведение что like, что = будет одинаковым и регистр не будет учитываться. читайте документацию, разделC.5.5.1. Case Sensitivity in String Searches
Даже если вы все это не знали, что мешает привести логон в нижний регистр и сравнивать с приведенными в нижний же регистр данными из базы данных?
А теперь представьте что у вас есть пользователи vasya и vas% . что вернет ваш like когда пользователь vas% будет проводить платеж?
Вы разрабатываете систему, связанную с деньгами. У вас явно недостаточно знаний/опыта. В вашем коде кучка простейших ошибок плюс кучка хитрых ошибок. Отдайте лучше эту часть кода разработать опытному специалисту, чессло, вам же дешевле это будет в результате.
присоединяюсь к вопросу, зачем like ? login этого проблемного пользователя очень хотелось бы услышать.
вообще очень сильно надеюсь что это псевдокод, а не настоящий. там же дырка на дырке.
PS я всегда считал что "пошлите денег на волшебный кошелек и получите в два раза больше" - это развод, но глядя на этот код уже так не считаю...
у меня вся статика на google app engine лежит.
не жалуюсь
...........
и очень правильно, в полном соответствии с теорией множеств, в которой where есть, а вот limit - нету
backlog действительно по умолчанию низкий для нагруженных серверов, даже без всяких атак, так что увеличивайте. возможно стОит увеличить порог срабатывания син-куков, т.к. вы увеличили очередь.
минус лично я вижу только один - если у вас почтовый сервер, то возможна ситуация когда почтовый клиент повиснет при попытке забрать почту во время атаки. самого сервера это никак не коснется. ну или ssh - тоже есть отличная от нуля вероятность что повесится при коннекте.
про другие минусы может быть madoff расскажет.
если вы пропишете единичку, то син-куки не включатся пока не будет атаки. порог включения-выключения определяется другим параметром (не помню напамять). поэтому имеет смысл говорить только о случае когда атака идет.
или я не понял ваш вопрос.
спрашивайте!
слышал я о кузнецове. товарищь D. J. Bernstein тоже слышал, кстати. вот буквально, как раз о син-куках
очень характерно, да? сказать че-нить, и в кусты. никого не напоминает :) ?---------- Добавлено в 01:04 ---------- Предыдущее сообщение было в 00:47 ----------
я прошу прощения, но как только мы подошли к чему-то конкретному, вы сразу заявили "учить не буду". а до этого я слышал только одно "резет!резет!резет нах!". когда я задал простой конкретный вопрос - кто и когда резет генерит - я получил ответ? ага, как же, разбежался. сразу в кусты.
ну, на нет и суда нет, я умолять не буду.
слава богу, не одним ру-нетом мир полон, благо английский у меня свободный. по-крайней мере в буржуй-нете брызгать слюной не принято, а принято объяснять в чем не прав.
PS кстати пару лет назад захаживал на форум сетевиков, забыл уже как называется, не моя специализация все-таки - очень, очень вменяемые специалисты. так что не все так серо в рунете.
хорошо поставленный вопрос содержит 50% ответа.
ну да ладно, я вижу что тут все настолько круто сваренные, что и спросить ничего нельзя, одни только крики в ответ. а как спросишь что-то конкретное - сразу либо в кусты, либо в гугл.
бог с ним, не на одних Одминчигах с серча свет клином сошелся.
ну как бэ понятно что куда отослали в логе не видно.
вы спрашиваете что будет если "кукисы не проверят те, куда отослали"? ответ простой - кукисы проверяет сервер, а не клиент.
вы спрашивайте, спрашивайте. глядишь, и докопаемся до истины.
