Никто не сталкивался с таким синтаксисом? Происходит просто вызов функции (это просто функция, не метод какого-то класса). А вот что дает упоминает константы и двоеточия в начале - для меня загадка.
Возвращаясь вот к этому. В ситуации, когда есть и CLIENT_IP и X_FORWARDED_FOR, и запрос проходил только через один прокси сервер, оба заголовка будут содержать один, и причем одинаковый IP. Вот при прохождении второго прокси, ситуация поменяется. В X_FORWARDED_FOR может быть дописан адрес первого прокси. Причем в зависимости от программы сервера в начало (сквид) или конец (мой случай). Вот вопрос, а будет ли перезаписан CLIENT_IP. Вот в чем вопрос то собственно. То, что он теоретически может быть перезаписан, я знаю. А вот практически?
Вот теперь я вижу совсем другой вопрос.
1. Он и клиентом(браузером / чем угодно) изначально может слаться какой угодно. Например, строка "розовый слоник".
2. Он может подменяться прокси сервером. И стираться. И Х_ФОРВАРДЕД тоже может.
MisHel64 пишет:
И по третей части. Подделать и обойти можно абсолютно все. Главное знать что обходить. А так как исходников в свободном доступе не будет, то знания эти придется добывать экспериментально.
Да ладно, принять http запрос и пернаправить его дальше и подправить что-то в заголовках - задача не особо сложная. Это на PHP на коленке делается без усилий.
Сложнее подделать REMOTE_ADDR - это не HTTP заголовок. Но вы знаете, что он дает адрес последнего узла. Остальное - не более, чем http заголовки, которыми пользоваться можно только для справки и доверять им стоит, но только как необязательно достоверному материалу.
1. Не выбираются лишние поля - снижается трафик между сервером БД и PHP. Соответственно, нагрузка и время чтения.
2. Если перечислять поля, и нам случайно так повезет, что все перечисленные поля есть в индексе, то СУБД прочитает значения из индекса, не читая целые строки, а это приятно.
3. Видно, с какими данными работает код, идущий после запроса. Это бывает приятно, когда надо узнать, скажем, где используется такое-то поле, если замышляется пересматривание структуры таблиы или еще что-то.
4. Если несколько джойнящихся таблиц имеют столбцы с одинаковыми именами, то лучше перечислить эти столбцы, указав им алиасы. А чтобы не забыть один из них, нужно следовать привычке перечислять все.
5. Другие ошибки, которые можно по невнимательности допустить, не видя перед глазами столбцы.
Постов номер 2, 4, 8 вы не читали, а обвиняете меня во невменяемости?
Пост номер 2 я читал (это тот, что со ссылкой на параллельную тему?) - поэтому я в курсе, что Вам всё давно ответили и не пойму, чего нужно.
Пост №4:
MisHel64 пишет:
Еще один...
Не дал мне ни информации, ни повода для размышлений.
MisHel64 пишет:
Который всех желающих обсудить "не частный случай", читай сферического коня в вакууме, отсылает в более другое место.
Я обсудил частный случа: ваш Х_ФОРВАРДЕД_ФОР и ваш КЛИЕНТ_ИП. И сказал, где в этом случае наиболее вероятный ип клиента, где прокси. Если это не ответ на вопрос, то уточните вопрос.
Но я упомянул про общий случай - можете это упоминание не читать.
Или Вас возмущает то, что кроме ответа на вопрос, Вам упомянули что-то об общем случае?
MisHel64, мне кажется, Вы не в себе. Вам ответили, откуда стоит брать адрес в Вашем частном случае и на сколько можно на него полагаться.
Какой вопрос остался неудовлетворен и почему? (Добавление)
Код по ссылке смотрели?
Может быть, это ответит на вопрос? http://ru2.php.net/manual/en/lan...s.predefined.php , коммент со словами
It's possible for a HTTP client to spoof HTTP_X_FORWARDED_FOR, and set it to a fake IP number. It's more secure to use this code and log BOTH the ip and the proxy ip. и кусок кода после него.
Но на самом деле, на достоверность этих адресов сильно полагаться не стоит.
В частом случае, адреса установлены, если мы считаем, что они достоверны, то код выше дает нам айпишник и прокси.
А почемму бы циклом не перегнать старую строку в новую писимвльно, считая по дороге кавычки и пропускач пробелы тогда, когда надо? Это, по-моему, самое простое, очевидное и унгиверсальное решение
Еще вариант - чтобы не создавать лишний индекс просто поменять порядок полей в UNIQUE KEY. Нужно site_id и to_widget_user_id поставить первыми. Это конечно если этот индекс специально так не оптимизирован под какие-то другие запросы
SELECT 0 n UNIONALLSELECT 1 UNIONALLSELECT 2 UNIONALLSELECT3/* ..... */
) t ON n <(SELECT count(*)FROM manager)
JOIN manager a2 ON a2.manager_id = substring(a1.gasc, n*5+1, 4)
JOIN manager a1 ON a1.manager_id = substring(a1.gdesc, n*5+1, 4);
group_concat / list / for xml path - есть практически везде, так что наверное им можно пользоваться. Количество юнионов зависит от количества строк, что не очень приятно. Хотя эту последовательность можно генерить. Вот такие минусы. Зато плюс: на моих данных (250 строк) Ваше решение выполняется 2.5с, а моё всего 0.167.
Вариант 2 - пронумеровать строки переменными и сджойнить (написал Мелкий).
Вариант 3 - пронумеровать подзапросом и также сджойнить. Сейчас напишу и померяю (Добавление)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 4334
