Поиск

Здравствуйте, есть e-commerce проект, хотим перевести его полностью на работу по https, с нормальным сертификатом от thawte или verisign (например). Что будет сделано: - перманентный редирект с http на https. В результате: - пользовательские данные будут лучше защищены при передаче их на сервер; - должно быть больше доверия к ресурсу (зеленая адресная строка); - ваши варианты?:). Какие могут быть по вашему мнению минусы от этого шага для SEO?

А в чем проблема с referrers? Только что попробовал - вроде бы все есть. Почитаю еще. ---------- Добавлено 04.04.2012 в 18:59 ---------- Вроде бы рефереры не сохраняются если будете переходить с HTTPS на HTTP, а если все будет внутри HTTPS - то все ок. Если будут переходы с HTTP на HTTPS - то вроде бы тоже должно быть ок.

Что плохого, если будет защищен весь сайт? Проблемы с индексацией - можно конкретнее, что вы имеете ввиду? Что помешает нормально проиндексировать сайт по https яндексу или гуглу??

Проблемы с индексацией, например. Сразу видно, что то ли от незнания ('перевести его полностью'), то ли от непонимания ('зеленая адресная строка'), вы делаете какую-то хрень, потому что типа так модно. Хотя на самом деле не модно. HTTPS'ом можно защищать кабинет пользователя, а не весь сайт.

vps (1Гб, 1,5Ггц, centos 6): nginx+apache, mysql, ispmanager lite - все установлено из панели (с небольшими танцами). не могу пробиться в phpmyadmin. при обращении к https://домен1/myadmin в логах было это: '/usr/share/phpMyAdmin/myadmin/ ' is not found. лишнее в ссылке myadmin, это решилось созданием ссылки. ln -s /usr/share/phpMyAdmin /usr/share/phpMyAdmin/myadmin. теперь в логах чисто, но при обращении к https://домен1/myadmin вылезает 403 ошибка: You don't have permission to access /myadmin/ on this server. как решить???.. какая еще инфа нужна для решения???. конфиги ниже ---------- Добавлено 04.04.2012 в 10:46 ---------- конфиг nginx:

_bl_, большое Вам спасибо за тестироваие моего сервиса. При проверке изложенных Вами сведений я обнаружил нюанс (баг), который позволял в некоторых случаях, неверно присваивать уровень анонимности прокси серверу. Дело в том, что при тестировании прокси выполняются несколько идущих подряд тестов, http, https, socks4, socks5 и т.д. В каждом тесте проверяется анонимность. Однако, если прокси, например, при обращении по протоколу http - прозрачный, а при обращении по https - элитный, то сведения об уровне анонимности прокси переписывались поверх, таким образом, уровень анонимности становился таким, каковым он был на самом последнем успешном тесте. Именно таким оказался указанный в примере сервер: 46.234.116.80, прозрачный по http, и элитный по https. Сейчас баг исправлен, и уровень анонимности от теста к тесту может только понижаться. Поэтому, если Вы проявили такое внимание к сервису потому что искали источник качественных списков прокси - можете провести повторный тест завтра, готов...

На данный момент наблюдаются проблемы с DNS-серверами сайта. Поэтому могут быть проблемы с его открытием, они решаются. Пока можете заходить в биллинг по прямой ссылке https://85.10.205.214/manager/billmgr Приносим извинения за доставленные неудобства.

До перехода на https были настроены событие onclick на скачивание?

У нас сайт который мы недавно перевели на https. Есть 2 проблемы: 1) /ru/forum/698350 2) По настройки отслеживании скачиваний. Если есть специалист готовый проконсультировать нас, мы готовы обсудить условия. Возможны консультации на постоянной основе.

сабж. у меня все ролики редиректятся на такую байду: 10.52.129.29:1081/. 10.77.205.138:8190/. и прочие вариации ипов. хотя главная ютуба открывается нормально, недоступны именно ролики (хотя встроенные работают). нашёл вроде решение, надо через https подключаться к ролику

Т.е. вместо того, чтобы вам еще раз пообщаться с тех. поддержкой по данному вопросу, вы как баран настойчиво сидите и ждете уже вторые сутки помощь от 'знающих ' людей ? От тех кто вместо того, чтобы дать ценный совет, занимаются @н@низм0м и жалуются на свои 'болячки ' и вещают как им хорошо где вас нет ))). Я полагаю вы заметили что вам никто ничего дельного так и не ответил ? Вы однако настойчивый товаришь ))). Собственно по сабжу. То что у тебя открывается другой сайт по https, это открывается дефолтный virtualhost на данном ip. И это нормально. Если это возбуждает в тебе плохие эмоции, включи в панели себе галочку SSL для данного сайта и тогда твой сайт будет работать по https ( если тебе это нужно). Если тебе https не нужен, перейди на выделенный ip ( чтобы не открывался левый сайт по умолчанию ) либо попроси, чтобы сделали заглушку вместо дефолтного сайта. Удачи в начинаниях!: Желаю побольше вам серьезных проектов и чаще улыбаться таким смешным тарифам 😂

Обнаружил, что из-за установленного на сервере устаревшей версии компонента ПО, чекер иногда ошибался в определении типа прокси. Сейчас софт обновлён и расширен функционал чекера. Теперь определяются не только SOCKS5, но и SOCKS4 прокси, кроме того, добавлена проверка поддержки HTTPS и возможности отправки POST запросов.

Я понимаю Ваши опасения, к безопасности я подхожу очень серьезно, изучение линукса начал с 1999 года, поэтому и ответственность понимаю. Сервис был написал в первую очередь для себя, если Будет интерес к нему ( сейчас активно с ним работают уже более 15 человек), то будет и дальнейшее развитие и усложнение( https, cnfr и пр. ) Буду благодарен за любые вопросы. Спасибо. п.с. Декскоп не интересен, так как это утопия. через два года на 2х-звенке будут работать только динозавры, которые хоть и будут утверждать, что это нормально, но на самом деле у них будет страх перейти на более современные средства. )

А если к вашему домену добавить ещё и /myadmin/ то попадёте в соответствующую 'программу '. А https это не вашего сайта, это панели. Вообшем там бардак.

Такая вот проблема: Если к моему домену обратиться по протоколу https, то показывается какой-то совершенно левый сайт. Это обнаружил не я, Гугл проиндексировал несколько страниц по этому протоколу. Мне предлагают зачем-то включать у каждого используемого домена ssl. Скажите, пожалуйста, неужели это действительно моя проблема как пользователя? Интересует мнение людей разбирающихся в хостинге, а не техподдержки Радиуса, с ними всё уже ясно.

Столкнулся с необычной проблемой: страницы сайта доступны по двум протоколам: HTTP и HTTPS. Видимо, по причине большой популярности сервиса Яндекс отдаёт предпочтение документам расположенным по HTTPS, что создаёт дубли в индексе. Как корректнее решить эту проблему? Будет ли адекватным решением закрыть https-версию сайта через (выдавать разные версии файла для http и https) и какие могут быть подводные камни у такого решения?

Если кому-то может быть интересно. Разные для версий сайта HTTP и HTTPS Яндекс отработал корректно и убрал из выдачи https:// дубли документов.

Функция наложения данных на страницу в разделе Статистики страницы не работает, хотя код установлен верно(остальныю статистику ведь показывает корректно). Выдает сообщение: В ваших настройках обнаружены ошибки. Они могут привести к проблемам при загрузке статистики страницы. Код на вашем сайте не загружается с сервера Google. Если код отслеживания Google размещен на собственном сервере, он не будет обновляться автоматически. Вы можете пропустить важные изменения. Не удалось найти фрагмент кода отслеживания на вашем сайте. Невозможно загрузить статистику страницы. Убедитесь, что код отслеживания был установлен правильно. Если фрагмент включен в отдельный файл JavaScript, необходимо вручную проверить его загрузку. Единственное подозрение на то, что мы перешли на https://, может повлиять?

Угу, для авторизованных пользователей теперь https

Ничего нового. Раньше авторизованных пользователей gmail-g+ насильно редиректило на https только с домена, теперь и с.