Это что было? Я даже не знаю, как реагировать на такой код. Вы всегда смешиваете всё в кучу: php, html, css, js...? Зачем вам нужно добавлять какие-то значения $row_s['nom']?
Насколько я вижу, это часть кода, который я вам писал в предыдущей вашей теме. Переменной "act" присваивается значение или "add", или "remove", которые берутся из data-атрибутов кнопок и используются в качестве имени метода. Скорее всего, что вы или же изменили эти значения, или вообще убрали атрибут data-, в следствии чего и возникла ошибка.
И не будет работать, т.к. прекращена поддержка YouTube Data API версии 2. Теперь нужно использовать третью версию API. Если лень разбираться, то можно, конечно, решение "в лоб". Только на мой взгляд, грузить всю страницу ради одного названия - это бред.
Mongrel, первое, что нужно делать в таких случаях - это заглянуть в консоль. Возможно, что вы там обнаружите какие-то ошибки или предупреждения.
P.S.
Mongrel пишет:
я понимаю так что php код не видит функцию java
Java !== JavaScript. Ну и тут такая печальная история, что PHP и JavaScript никогда друг друга не увидят, т.к. один работает на клиенте, а другой на сервере.
Во-первых, нет смысла для такой задачи использовать изображения. Во-вторых, не ясно, что должно происходить при повторном нажатии на кнопку. В-третьих, месяц назад уже утвердили ES6, а вы события устанавливаете по старинке. В-четвертых, Viper и Tyoma5891 вам показывали варианты с использованием jQuery, хотя и не понятно почему, если ваш код указывает на то, что вы используете ванилу.
В общем, пока покажу вам такой вариант, где повторный клик переключает состояние кружков. А если уточните вопрос, то подкорректируем:
Приветствую, господа! Появилась задачка, которую без проблем можно решить, если некоторые расчеты производить в php, но стало интересно организовать это всё в самом запросе.
Предположим, что смена сотрудника длится с 10-ти утра текущего до 10-ти утра следующего дня. Необходимо вытащить записи за текущую смену и естественно опираясь на текущее время (что-то дофига слов "текущий" ). К примеру, если сейчас >= 10 часов, то выбрать в диапазоне от 10:00 текущего дня, до 10:00 завтрашнего. Если сейчас < 10 часов, то с 10:00 прошлого дня, до 10:00 текущего.
Повторюсь, что на php это решается достаточно просто и всего парой строк, но как по уму организовать эти условия и проверки в самом запросе? Пока дошёл до такого варианта, но что-то он мне не особо нравится:
С этим я уже успел познакомиться и знаю, что рекомендуется TLS1.1, TLS1.2 и исключить SSLv3 и ниже, и некоторые советуют даже TLS1.0
И спасибо за ответы.
Думаю, что этот вариант не подойдет в конкретно этом случае. Но за время, пока я задал вопрос, кое-что изменилось, а именно то, что похоже я убедил в необходимости использования SSL. Тогда остаётся вопрос в том, а нужно ли что-то менять в той схеме аутентификации, которая существует, если использовать SSL ? Насколько я понимаю, то в хэшировании на стороне клиента уже необходимости нет. Нормально ли хранить в сессии случайно сгенерированный хэш, который будет служить для идентификации пользователя и использовать этот же хэш в качестве токена - нет ли тут проколов? И вообще, может что-то желательно добавить или убрать?
Мелкий пишет:
Баз кропотливого анализа кода ничего не говорит.
До изучения этого вопроса пока не дошёл, но поверхностный анализ "пациента" показал, что всё нормально. Данные обрабатываются фильтрующими функциями (filter_input, filter_input_array), используются плейсхолдеры и т.д.
Мелкий пишет:
Пароли шифроваться не должны. Пароли должны хэшироваться.
Всем привет! Как-то не особо углублялся в вопросы безопасности, но сейчас появилась задача, которая толкает в этом направлении. Материалы, которые находил в сети, или же писались лет пять назад, или противоречивы, или не затрагивают важных вопросов. Посему, хочу посоветоваться с сообществом.
Опишу конкретную ситуацию. Попросили меня поработать над безопасностью одного проектика:
Есть уже работающая, небольшая и самописная CRM-системка. Как я понимаю, начинали её писать давненько и дорабатывалась разными людьми.
Работает по http-протоколу
Сайт не для общественного пользования, не имеет открытой системы регистрации. (босс конторы сам заводит аккаунты сотрудников)
Пароли шифруются по алгоритму CRYPT_BLOWFISH
PDO - для работа с БД
После аутентификации, генереруется случайный хэш, который записывается в БД, сессию и на клиенте в localStorage для добавления ко всем ajax-запросам (в качестве токена). При кадом запросе хэши сверяются.
На сайте единая точка входа.
99% запросов передаются с помощью Ajax и только методом POST, а всего 15 - GET-запросом. POST-запросы без Ajax-а - блокируются.
Я понимаю, что SSL или авторизация по СМС - это лучшие вариант, но задача состоит в том, чтоб найти альтернативные варианты. Да и сверхсложной системы безопасности там не нужно - нет банковских операций, нет личных данных пользователей или данных о счетах. Видел решения с шифрованием пароля на стороне клиента. Я может ошибаюсь, но если это обратимое шифрование, то какой от него толк?
В общем, посоветуйте как, можно услить безопасность:
1) Какие есть ощутимые уязвимости из того, что я описал выше?
2) Как можно защитить передачу пароля от клиента на сервер.
3) Как идентифицировать пользователя поле того, как аутентификация пройдена.
4) Что нужно хранить в сессиях и нужно ли проверять пользователя при каждом запросе.
Честно говоря, от избытка информации за последние два дня, я уже запутался. Интересует практически всё по этому вопросу, т.к. даже те знания, которые у меня были по безопасности, уже под сомнением.
Вопрос этот, я уже поднимал на другом форуме, но вразумительно ответа, кроме как - "только SSL" - я не получил.
зачем вам тогда апач если у вас ПХП работает в режиме CGI?
Досталось, так сказать, в наследство )) Сейчас что-то менять глобально нет возможности. На сервере работают 23 сайта, которые куда-то переселять на время реорганизации - это большой геморой.
esterio пишет:
такие вызовы ка eval без сухосина вам не запретить
Речь пока идет не о каких-то отдельных настройках или закрытии дыр, а о конфигурации в целом. А за Suhosin спасибо, почитаю.
Ch_chov пишет:
Врядли получится, потому что конфигурация считывается только из одного php.ini файла.
Тут вы ошибаетесь. В том способе, который я пока использую, у меня сканируются все конфиги из директории "php.d", а затем пользовательские. Настройки читаются из обоих файлов, но общий перекрывает директивы пользовательские.
Ch_chov пишет:
выставлять значения некоторых php параметоров в настройках nginx
Приветствую! Для начала, общая инфа:
1. Centos 6.5
2. Nginx 1.6.2 (front-end) + Apache 2.2.15 (back-end)
3. PHP 5.4.33 - в режиме CGI
4. ISPManager 4
Суть проблемы:
У каждого виртуального хоста, есть свой пользовательский php.ini (в общем, это и так понятно), в котором по умолчанию описаны две директивы: sendmail_path и session.save_path. В глобальном php.ini ("/etc/php.ini"), прописал все общие необходимые настройки. Однако, эти настройки не подхватываются. К примеру, прописал я для "disable_functions" список функций в общем php.ini, рестартонул Apache и на любом виртуальном хосте, та же функция exec() выполнится без проблем. Если директиву прописать в пользовательском файле php.ini, то всё отрабатывает как и полагается.
Как решил на данном этапе:
Создал файл php.ini в директории "php.d", где и прописал все необходимые директивы, которые распространяются на все хосты.
Что не устраивает:
Приоритет php.ini в директории "php.d" имеет приоритет выше, чем пользовательский. Да, если смотреть относительно той же директивы "disable_functions", то это можно считать плюсом, но в большей степени - это всё же минус. К примеру, в общих настройках, я укажу временную зону Гондураса. Тогда юзер уже не сможет эту зону изменить в своём php.ini.
Что хотел бы иметь в идеале
Собственно, обратную приоритетность. То есть, если в пользовательском php.ini не прописана какая-то директива, то она подхватывается из общего php.ini, а если директива прописана у юзера, то именно она вступает в силу.
Буду признателен, если кто-нибудь подскажет, как это лучше сделать.
Всем привет! Для упрощения, взял абстрактную задачу, аналогичную существующей.
1. Есть таблица с заказами, в которой каждый заказ привязан к менеджеру
2. Вторая таблица - содержит записи ID-заказа и ID-менеджера, которые должны игнорироваться.
Нужно: Выбрать из талицы заказов те записи, которые есть у определенного менеджера, но которых нет в таблице с игнорируемыми заказами у этого же менеджера.
Пример закинул в песочницу (url с хешем "режется" на форуме, посему ссылка TinyURL), где есть два менеджера и для первого (с ID = 1), есть два заказа, которые не должны учитываться при выборке.
На данный момент, есть запрос, который исправно работает, но хотелось бы оптимизировать:
Где в плейсхолдер (?) подставляется ID менеджера.
Толи я не выспался, толи что-то у меня сегодня с руками, но через JOIN переделать запрос не получается. Буду признателен, если подтолкнете в нужном направлении.
вроде бы разницы нет, но просто для успокоения души - есть ли подводные камни в использовании того или иного, может для определенной версии мускула важно использовать конкретный синтаксис? В документации не нашел каких-то предостережений, но мог и проморгать.