Представете си, че намирате една много интересна за вас информация. Например – колко директори на училища са били агенти на ДС. Сега си представете, че искате да споделите тази информация с някой. Как го правите? Лесно – копирате адреса и го споделяте я във Facebook, я в Twitter, я по мейл на горките си колеги. Те отварят линка и получават информацията.
Не обаче и ако става въпрос за Държавна агенция „Архиви“. Там може да намерите архивите на Политбюрото, полицейските досиета от преди ’44, имената на загиналите през Балканските войни и документи от еврейската общност. Работата е, че може да ги откриете само, ако отворите сайта archives.bg. Ако ги отворите през Google или споделена връзка (както тази в предишното изречение), ще видите грешка „403 Забранено“. Това на прост език означава, че на ДАА са забранили някой да споделя каквото и да е от сайта.
Страница отворена през линк и директно през сайта им.
Разбира се, след като видите въпросната грешка, може да презаредите страницата и тя ще се отвори нормално. Така се изчиства състоянието, че сте препратени от друг сайт и ДАА не ви блокира. Стандартната реакция на всеки обаче е да затвори прозореца, тъй като явно става дума за сгрешен линк. Всичко това може, разбира се, да е техническа грешка. Не се сещам обаче за ситуация, в която да се е случило. Освен може би, ако са искали да блокират някой конкретно, а са блокирали всички. (Погледнете и тезата на Михаил в коментарите) Навярно нямаме и основание да спекулираме, че има общо със смяната на шефа на агенцията с човек от МВР.
Открих този проблем с добавката за WP за търсене на счупени линкове. Потвърдих, че не са блокирали само мен като отворих линкове от чужди сайтове. Имам проблеми да заредя страниците и през автоматичните ми скриптове за теглене на информация.
Още по темата:
Възпоменание в Twitter на загиналите през Балканските войни
Отворени данни за загиналите войници през Балканските войни
Отворени данни за сътрудниците на Държавна сигурност
Прозрачността в градската среда и това да си деен не само по избори
Блокирането на request-и по HTTP referer е доста найвно в повечето случай, тъй като хедарът лесно може да бъде променен или манипулиран.
Например в chrome:
https://chrome.google.com/webstore/detail/referer-control/hnkcfpcejkafcihlgbojoidoihckciin/related?hl=en
или пък:
[dpetrov@debian: /tmp]$ curl -I http://archives.bg/politburo/images/igallery/resized/163901-164000/12009089_001_m-163976-500-800-80-wm-center_middle-100-daapng.jpg -e http://archives.bg
HTTP/1.1 200 OK
Date: Tue, 26 Nov 2013 08:58:39 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Sun, 26 May 2013 13:47:48 GMT
ETag: „3f8f9d6-9d61-4dd9f4706a900“
Accept-Ranges: bytes
Content-Length: 40289
Content-Type: image/jpeg
@ДП – естествено, че е глупаво, но е достатъчно, за да попречи да се споделят директни линкове към сайта.
@Боян Юруков – за голяма част от хората ще е пречка да, но все пак има няколко варианта.
Например:
1. Ако се използва някоя услуга за скриване на реферара: Архиви
2. Ако линкът идва от сайт, който е през https
3. window.location също не би трябвало да изпраща referrer в хедарът
@ДП – Няма спор, че има заобикаляне на забраната. И в статията съм написал, че е достатъчно дори посетителя да презареди страницата. Глупаво е, че се налага да го правим. Писах на агенцията да ги питам защо го има това и ако е грешка, кога ще бъде оправено.
Ако ги пускаш през Annonym.to няма ли да работят? Примерно така: http://anonym.to/?http://www.archives.bg/
@Пепо – може да се заобиколи по много начини. Не е това въпроса. Писна ми да заобикалям безсмислени защити. Трябва да го оправят.
Впрочем Михаил пусна доста добро обяснение във фейса:
Добре де, някой писа ли им на тези от Архивите за проблема?
Вероятно е от недоглеждане и зле разбрана „защита“.
@Красимир Гаджоков – Писах им веднага като открих проблема. Не получих отговор, но сега виждам, че наскоро са го оправили.