Просмотрел, что IServer наследует от ITcpSocket, сори.
Server 2 раза наследует IServer - то о чем ниже пишет Ринат Велиахмедов, как из двух методов load он должен вызвать?
Вообще множественного наследования лучше избегать, если точно не знаешь, что делаешь.
Тогда второй вариант - с помощью bcp.
Можно выгружать не всю таблицу, а попробовать вариант инкрементной выгрузки нужных таблиц во внешний файл. Например выгружать записи по условию ID > последнего_выгруженного_ID.
С bcp можно такое организовать.
BCP запускать из шедулера, затем полученный файл упаковать и скачивать по мере необходимости.
В общем я хочу, что бы вы определились чего же хотите от этого алгоритма, т.к. надежная аутентификация и защита от дурака - разные вещи и требуют разных подходов и алгоритмов.
На счет МД5 - алгоритм давно взломан, есть эффективные методы поиска коллизий. Не уверен, что по хэшу и известному К1 можно найти SALT1, но я тут не особо в теме.
SHA1 так же ломается, но требуется больше вычислительных ресурсов.
Взлом хэш алгоритма заключается в нахождении коллизии на известный хэш, т.е. нахождение такого значения хэш которого будет таким же, как известный хэш. Это значение не обязательно должно совпадать с искомым паролем (поэтому и зовется коллизией). В любом хэш алгоритме есть коллизии, дело только в том на сколько долго их находить. Как правило подбор в лоб - процедура очень затратная (иначе не было бы смысла заморачиваться ни с хэшами ни с криптографией), но используя определенные особенности (уязвимости) алгоритмов можно найти способ для более быстрого нахождения коллизий. Для МД5 такой способ найден.
HMAC - это вообще не хэш алгоритм и не алгоритм криптографии, смотри википедию. Поэтому использовать MD5 или HMAC-MD5 - стойкость одинакова, такая какую выдает МД5, т.е. никакая.
На сегодня актуальны и пока не сломаны алгоритмы из состава SHA2, например SHA256 или SHA512. Можно использовать их.
И нужно отказаться от хранения постоянного общего секрета (SALT), его надо вырабатывать на лету, например по алгоритму Диффи-Хелмана, а дальше шифровать трафик каким-нибудь 3DES, AES или нашим гостом.
А если прикрутить сертификаты, то можно использовать SSL.
Ну вот. Сразу бы так. :)
Подойдет ваш алгоритм, о чем я пишу уже третий пост. Думаю, что в вашем случае особо задаваться вопросом про "возможные уязвимости" и использованием МД5 не стоит. Вряд ли "фигня" догадается по случайному числу рассчитать МД5 и запихнуть все это на вход замку.
Вот если бы речь шла действительно об аутентификации, то совсем другое дело, ваш алгоритм был бы не пригоден..
Ну и посылайте open открытым текстом - для "защиты от дурака" достаточно.
Хотя я бы послал по длиннее строку.
Мне не ясно предназначение алгоритма. "Защита от дурака"? Если да, то пойдет и такой или "open". Чего вы хотите от этого алгоритма?
token: На сколько я понимаю, этот алгоритм должен обеспечить не срабатывание замка, на какие-либо случайные сигналы и помехи. Если да, то, имхо, вполне подойдет. Но он обеспечит только это - "защиту от дурака".
Для чего-то более серьезного не годится, т.е. я имею ввиду, что при желании любой "не дурак" зная алгоритм и имея замок сможет собрать свой собственный ключ.
SyavaSyava: Согласен.
Лично мне ваше предложение больше нравится, оно, так сказать, более технологично и обрубает возможность убить процесс на корню. Потому и проголосовал за него :)
Как-то так:
select distinct p.name from products p
join char_product cp on cp.id_product=p.id and cp.id_characteristic in (select id from characteristics_value where value in ('white', '64Gb'))
Dima_kras: только на будущее учти, что операция IN - это не ИЛИ, это проверка на вхождение в множество. В данном конкретном случае лучше использовать IN. Но когда действительно понадобиться ИЛИ, нужно использовать OR.
В нетстат отображаются все процессы, участвующие в сетевом обмене. Ничего удивительного, что там и скайп присутствует.
И то что ты "расшарил" свой сервак, еще не говорит о том, что пакеты куда-то ходят наружу. Если и клиент (браузер) и сервер (апач) на одном компе, то нет смысла пакетам ходить на роутер, они и не ходят :)
exeragub: можно обойти, если будет шара доступна - на шару кладешь файл флаг, в шедулер на удаленном компе батник, проверяющий наличие фалага и при наличие выключающий комп.
Вообще по уму завести везеде админа с одним паролем, иначе этот зоопарк вообще не управляемый будет.
Алексей Лебедев: У вас только один запрос к базе и таблица в базе одна? Наверняка есть таблицы, которые ссылаются на эту таблицу по ее id, тогда понадобится индекс по id, а т.к. id как правило заведомо уникальный, то по нему лучше сразу строить уникальный кластерный индекс. Если id нигде больше не используется, то зачем он тогда вообще нужен?
И да, отдельные при and. А что смущает?
Slava Kryvel: Cttr: На микротике маршрут можно не прописывать, т.к. маршрутизатор по умолчанию на нем и так убунта.
На счет отказа от 88 сети: можно в микротике и убунту и все компы 88 сети воткнуть в ЛАН порты (не уверен есть ли в микротике разделение на LAN/WAN, никогда их не щупал живьем) и раздать всем адреса из одной подсети (192.168.2.0), тогда и маршрут не потребуется.
Cttr: Нет, не хватает на убунте магического route add. Синтаксис не скажу, надо гуглить или смотреть ман на убунте. Что-то вроде:
route add 192.168.88.0\24 192.168.2.2
Cttr: изменится - не нужно будет пробрасывать порты. Маршрутизаторы по умолчанию у вас везде нормально выставлены, поэтому все сети друг друга будут видеть без дополнительных настроек. Без НАТа сможете ходить на прямую, по IP или по имени хоста (если ДНС есть). Slava Kryvel: убунта с двумя сетевыми интерфейсами, логично предположить что она, кроме того что выступает шлюзом, может и фильтровать трафик, благо возможность эта есть. Мы же не знаем в деталях конфигурацию сети.
Убунту имеет адреса в обеих подсетях (192.168.2 и 192.168.1) , поэтому там маршруты уже есть, а шлюз по умолчанию в убунте в данном случае не принципиален.
Микротик маршрут к 192.168.1 то же найдет с такими настройками.
А что на хостах в подсети 192.168.88 в качестве шлюза по умолчанию?
Но маршрутизация это только пол дела, нужно удостоверится что на убунте трафик не блокируется фаерволом или НАТом.
Кстати и на микротике, возможно включен фаервол, который может блокировать нужные порты.
Для проверки можно воспользоваться тем же телнетом, например, с хоста 192.168.1.2:
telnet 192.168.2.2 <проброшенный порт>
И кстати, зачем на микротике НАТ? Он еще в интернет смотрит?
Нет про доступ к 192.168.88 - это я загнул.
Но после того как на микротике пробросишь порты, надо удостоверится, что убунта разрешает доступ к этим выделенным на микротике портам. На убунте ведь то же шлюз, возможно и фаервол и что-нить еще (типа НАТа), поэтому на этом этапе то же вполне может резаться.
И еще важный фактор - что стоит шлюзом по умолчанию на микротике, на компах в сети 192.168.88? Возможно потребуется прописывание маршрутов на микротике и на компах в этой сети.
