Домены AD и DNS - и то, и то одновременно. Крутится IIS, но он крутится на самом сервере (а какую погоду это играет?). На виртуалке он тоже в планах, т.е. я предполагал такую логику: запросы к домену company1 будут отправляться на локальный IIS, а запросы к домену company2 будут улетать на IIS виртуалке. Очень хочется решить проблему штатными средствами, а не разворачивать "того, кто разруливал бы".
John Smith: Нельзя в полной мере доверять HTTPS. Да, это весьма защищенная вещь, однако при подмене самого сертификата, Вас она не спасет. Для таких ситуаций, например в вебе, самый дефолтный Apache при создании сессии отправляет клиенту куки, предположим это хэш случайного числа. Он сохраняет в своем хранилище кем Вы являетесь и какой у вас хэш, и затем быстро вас распознает, т.к. клиент присылает ему хэш, который был передам ему в свою очередь от сервера. Таким образом, если злоумышленник попытается начать прослушивать трафик между сервером и клиентом, все что он узнает - это хэш сессии. Даже не хэш пароля, а уж тем более не сам пароль. Это лучшее из возможного, ведь пользователь не будет деанонимизирован (его личные лог/пасс). + ни в коем случае нельзя хранить в открытом виде пароль клиента в БД, самое то - это хэш пароля, да побольше.
Александр Пожарский: Если злоумышленник имеет доступ к компьютеру владельца и может извлечь из хранилища клиента хэш, то почему злоумышленник не может извлечь так же куки или сохраненную пару лог/пасса? Если утекает пароль, хэш сменится на стороне сервера, точно так же как и должна разорваться сессия. Весь смысл в том, что в любом случае, даже если Вы авторизуетесь, сервер должен будет узнавать кем вы являетесь - он должен выдать вам куки или каждый раз вы должны передавать пару. Третья сторона при скомпромитированном соединении сможет получить доступ к этим данным. Тогда в чем тут волшебная защищенность и существенное отличие от передачи хэша пары сразу? Ее тут нет. В любом случае будут выполняться одинаковые ситуации защищенности, разница лишь в количестве выполняемых действий. Моим способом Вы сразу передаете хэш и сервер не используя третьего хранилища кук может сразу понять кто вы, обратившись к бд с сохраненными хэшами. Вашим же способом, сервер должен либо каждый раз генерировать хэш из получаемой пары и искать ее в бд, либо же выдавать куки, и хранить их в своем третьем хранилище. Если сразу пересылать пару, а не куки или хэш, то вы вдобавок еще и рискуете скомпрометировать пароль клиента (вероятность кражи выше, чем вероятность кражи например при куках).
Перечитайте внимательно вопрос. Я не спрашиваю КАК мне надо решить задачу. КАК решить эту задачу уже известно. Здесь речь про регулярное выражение, которое надо составить.
Да, строго по порядку + отсортированы по убыванию, как надо. Однако в примере в качестве id выступает просто номер, а на рабочем проекте используются даты с точностью до минуты. Я предполагал что в предложенном варианте решения будет просто номер строки из отсортированного набора, который можно прибавить и всё, однако в вашем варианте придётся как-то увеличивать минуты.
Очень нравится ваш предложенный вариант, но не могу сделать столбец с числовым ID - все значения с датами добавляются асинхронно и соответственно ID не будут по порядку в случае сортировки по дате
tsarevfs: длина - несколько десятков миллионов записей (записи ведутся аж с 2000 года). Длина последовательности произвольная, но чем больше, тем лучше. Линейный поиск - думал, но как реализовать "похожесть", то есть вероятность небольшого отклонения, но в целом значения похожие?
Александр Таратин: Да, контейнер есть всегда, только как я написал выше, при диспатчинге Вашего события мы получим не клик, по заданным координатам, а клик по расположению верхней левой точки объекта, который будет лежать среди заданных нами координатах
Александр Таратин: хорошо. Давайте рассмотрим задачу с другого угла. Предположим, у меня есть Яндекс.Метрика, которая слушает все события, которые происходят на странице, включая движения и клики мыши по координатам. И если мы будем диспатчить преложенные Вами события через координаты объектов, то получим весьма странную картину - в Метрике мышка будет скакать по экрану, а клики будут происходить по верхнему левому углу элемента. Совсем другое дело, если мы будем эмулировать движение и клики через координаты.
Александр Таратин: дык задачка диспатчить клик не на элементе, а по абстрактным координатам внутри заданного dom. А по Вашей ссылке мы сначала получаем элемент из координат, а потом только по нему искусственно кликаем.
Если посмотреть на мой пример в вопросе, то там видно что сначала получаем элемент, внутри которого будем кликать, а потом эмулируем событие либо движения мыши, либо клика по заданным координатам. Вполне возможно что в этих координатах будет пустота, поэтому искать элемент там элемент не имеет никакго смысла :) Однако, за такую вкусную функцию спасибо, не знал о такой :D
