В допълнение към темата за добрите практики при работата със свободен софтуер. В частност — разработката на уеб-услуги. Често ви се е случвало интересът към даден сайт да ви бъде спрян от задължителна форма за регистрация, въвеждане на пароли и т.н. Много хора приемат всичко това за нормална даденост, но все пак поне веднъж сте се питали “защо ми искат изобщо регистрация тук”, нали?

Разработката на уеб-страници има много особености, някои от тях строго специфични, много на брой и многообразни. Но има някои общи правила, които е важно винаги да се спазват. Това са общовалидните препоръки за проектиране, писане и поддръжка на качествен сайт. Разбира се, сайтове могат да се правят и с пренебрегване на такива препоръки и в мрежата има огромен брой примери за това. Но ако полагате грижа за даден сайт, бил той личен блог, галерия или портфолио, бил служебен представителен сайт на фирмата или пък бил еднократна поръчка към външен за собственика специалист, част от правилните, добри грижи за сайта включват и съобразяване с тези общи правила. Ще опитаме да разгледаме поне част от тези “препоръки за добрата практика” при правене на сайтове.

Имаме ли нужда от пароли?

Въпросът звучи реторичен и като че ли подразбиращият се отговор е утвърдителен. Но нека помислим пак — имаме ли наистина нужда да искаме от потребителите си да ни дават парола за достъп до сайта? Този въпрос е може би основният за решаване при работата с пароли в разработката на страници. Може да го разделим на две части — “За какво са ни пароли?” и “Как ще ги съхраняваме?”. И двата въпроса могат да имат различни отговори, които изобщо не са “предопределени” от някаква уеб-тенденция за искане или неискане на пароли. Трябва да отговорим за конкретния сайт, по който работим и на двата въпроса, да намерим правилното им решение.

Водещо правило при обмислянето на тези два въпроса е “колкото по-малко, толкова по-добре”. Това означава, че подробното и излишно утежнено занимание с пароли изобщо няма да помага на сайта ни. А напротив — ще пречи, като затруднява писането, изпробването и поддръжката му. Пароли трябва да се ползват само и единствено ако са наистина нужни.

За какво са ни пароли?

Много сайтове излишно искат удостоверяване на потребителите си. Трябва много точно да се обмисли каква е целта на сайта, кои действия на потребителя в него са ценни и по какъв начин. Дали например увеличават и подобряват съдържанието му, дали правят така, че потребителят да прехвърля пари на сайта за заплащане на някаква услуга или дали, например са действия, от които печелим от трети лица, като да кажем презареждания на реклами от платени рекламодатели.

Във всеки случай е важно да се прецени дали тези “ценни” действия на потребителите задължително трябва да се придружават с регистрация и влизане с парола. Ако регистрациите и паролите са ни излишни, най-добре е директно да ги пропуснем изцяло. Един добър сайт има достатъчно много други неща, върху които можем да се съсредоточим.

Ако все пак наистина е нужно потребителите да се идентифицират пред сайта, трябва да продължим да си задаваме въпроса “за какво са ни пароли”. Защото в Интернет има поне дузина разпространени начина за автентикация и този с локална за сайта комбинация от идентификатор и парола е само един от тях. Вярно, най-разпространеният може би. Но и най-трудният за поддръжка и най-уязвимият. Паролите се крадат, базите от данни се повреждат и такива инциденти определено не са в полза на потребителите. Или на поддържащите услугата.

В случай, че идентификацията е наложителна, непременно трябва да се обмисли използването на механизми, независещи пряко от сайта. Най-добре е, ако тези механизми зависят и принадлежат на самия потребител. Такъв механизъм за идентификация е OpenID. При него потребителят има пълен контрол върху сайтовете, на които се “доверява” и на идентифициращите машини, които OpenID-адресът му ползва. OpenID е много удобна възможност както за администраторите и разработчиците, така и за отделните потребители. Сваля от плещите на администраторите постоянната грижа с базата от данни с пароли и позволява на потребителите във всеки момент да прекратят акаунта си, като просто “изключат” доверяването към дадения сайт. или пък да променят идентифициращия сървър, като в специален таг в страницата си пренасочат идентификацията към друг нов сървър.

Трябва да се има предвид, че OpenID не е система за автентикация или оторизация, а само за идентификация. Затова е идеален за ползване в сайтове, където е важно да се знае кой е даденият потребител. Но за работа с финанси, лични данни, пароли и друга чувствителна информация вече трябва да се използва система, която да гарантира на нас, а не на външен ни OpenID-сървър кой точно е този потребител. Повечето готови системи за изработка на сайтове имат приставки за включване на влизане в акаунтите през OpenID.

Освен OpenID има и други системи за идентификация, като MicroID или Live ID на Майкрософт (известно преди като .NET Passport). Важно при избора на такава система е и дали е централизирана или разпределена. OpenID например е разпределена система, докато Live ID е централизирана и изцяло под контрола на Майкрософт. OpenID е с публикувана спецификация, докато Live ID е “walled garden”, затворена система на фирмата Майкрософт. MicroID пък е начин да се идентифицира дадена публикация в мрежата. Тоест тя не сработва като начин за “влизане” на потребителя в сайта, но веднъж идентифициран по друг начин (с OpenID или пък с парола), неговото съдържание в сайта може да бъде направено автоматично разпознаваемо с добавяне на MicroID-тагове.

Как ще съхраняваме паролите?

Става дума не толкова за хардуерното обезпечаване и дублиране на сървърните системи, а за чисто софтуерната концепция на съхранението. Накратко, паролите никога не трябва да са в явен вид. Може да звучи “изкушаващо” за бъдещия собственик на сайт да знае, че може във всеки един момент да провери паролата на даден човек и да направи нещо нередно — например да влезе като него, да му смени данните, да му открадне акаунта и др. под. Но това е несериозно и опасно. Не само че е неетично, а и при доказана зла умисъл потребителят ще е в правото си да съди такъв собственик на сайт.

В случай, че пароли в явен вид се откраднат от сървъра, дори и веднага да реагират администраторите и да започнат да предупреждават потребителите (например по е-пощата) в най-скоро време да влязат и да си сменят паролите, защото е имало компрометиране на сайта, пак тези, в които е базата с явни пароли ще могат много по-бързо да влязат във всеки един акаунт, да сменят паролата с тяхна си нова и така да “превземат” всички (или поне огромна част) акаунти на сайта. Ако паролите са шифрирани, времето за разбиване на шифъра ще е достатъчно да се реагира правилно и даже потребителите да имат възможност да си сменят паролите и да си запазят акаунтите.

Паролите трябва да са шифрирани или поне криптирани по някакъв отнемащ време за разкриване начин. “Криптиране” е общият термин, с който се обозначава всякакъв вис “скриване” на информация с видимото й преобразуване. Ако преобразуването пък я прави “невидима”, тогава процесът се нарича “стеганографиране”. “Шифриране” пък е такъв вид криптиране, при който данните се преобразуват според някаква формула, шифър, ключ. Има различни видове шифриране, според това дали са еднопосочни или двупосочни, дали се ползва двойка ключове (т.нар. “ключ и ключалка”) или пък според това какво ниво на сложност използват.

Във всеки случай паролите, независимо дали се пазят във файл, бил той и защитен по някакъв начин, например извън уеб-папките, или пък се пазят в SQL база от данни, трябва задължително да се замаскират — най-добре с шифриране. Това не е труден процес, всеки съвременен език за програмиране на уеб-страници позволява съвсем лесно да се работи с шифрирани пароли. Някои системи за сайтове (CMS, Wiki, blog и т.н.) поддържат вътрешно автоматично шифриране на паролите. Даже всички разпространени и развити готови системи (Wordpress, Drupal, Mediawiki, Joomla, Mambo, PhpBB и безброй още други) идват с интегрирано шифриране на всички пароли.

Тази тема е малко встрани от новините за свободен софтуер. Но понеже много хора използват свободен софтуер за страниците си в Интернет, много често без самите да знаят за възможностите, които им дава това и за многото начини, по които могат да експлоатират услугата на хостингите, ползващи свободен софтуер, нека поговорим за уеб-пренасочванията.

Всяка заявка до уеб-сървъра Apache получава някакъв отговор. Той в повечето случаи е невидим за потребителя на сайта, защото е задействан, но не е предвиден за показване или защото е предвидено от програмистите и администраторите да се показва, но не е бил задействан. В първия случай става дума за кодове за “нормално състояние”. Например отговор, че обектът се доставя или отговор, че обектът е преместен и може да се намери на еди-кой си адрес. Във втория случай става дума за кодове и придружаващите ги обяснителни съобщения, които означават някаква грешка. Била тя в сървъра, задействана от самия сървър, средата му или уеб-приложението или била от страна на клиента, в браузъра му.

Кодовете за състоянието на заявките се изписват в лог-файловете на сървъра, най-често в шестото поле на всеки ред. Полетата са разделени с интервал и някои от тях (например тези, които могат да съдържат разделителя, интервал в себе си) са оградени в кавички. Въпросното шесто поле съдържа трицифрено число, което е кодът за състоянието на заявката, върнат от сървъра. Тези кодове са доста и различни, но най-често срещаните и най-използваните при разработката на сайтове и проверката за грешки са сравнително малко на брой.

Тези от тях, които се отнасят до пренасочванията, започват с цифрата 3. Добре е всеки с интереси и занимания в областта на уебсайтовете, правенето, администрирането и поддържането им, или казано накратко всеки имащ нещо общо с HTTP да ги познава. Много често бързото поставяне на пренасочване е важно за оптимизацията на сайта за търсачки и за “задържане” на потребители при преместване, например.

Когато се настройва сървърът да връща код 3хх (някое от пренасочванията), задължително е и да се посочи като допълнителен аргумент адресът на пренасочването. Тоест къде да отиде клиентът, след като сървърът му е казал “има пренасочване”. Адресът се изписва като стандартен URI-запис, тоест включва протокол, сървър, евентуално порт и евентуално път — http://example.com:8080/newsite например.

Видове пренасочване

постоянно (permanent) — връща се код за състояние “301” и това означава, че съдържанието е постоянно преместено на указания нов адрес. Предполага се, че настолните приложения и индексиращите машини на търсачките автоматично при посещение на адреса с постоянното пренасочване ще променят данните си. Например Google ще знае за новия адрес и вече ще показва предимно него и браузърите при посещаване на такъв сайт сами ще си променят записа в отметките си. Все пак трябва да се има предвид, че такава “миграция” за търсачката на Google отнема от месец до два или три. Чак след това се възвръща и PageRank-а, който при такова преместване в началото се нулира за новия адрес.

временно (temp) — връща се код за състояние “302”, което означава, че временно съдържанието е на новия адрес. Ако е използвана директивата Redirect в настройката на сървъра (или съответно в .htaccess), но не е указан изрично кой код да се върне, това е подразбиращият се код.

замяна (seeother) — връща се код за състоянието “303”, показващ че съдържанието е било заменено и всичко, което е било на предишния адрес, сега е смислово заменено от съдържанието на новия адрес. Това не е точно пренасочване и в днешното време на използване на аргумента “rel” към препратките за изразяване на смислово отношение се ползва много рядко.

премахнато (gone) — връща се код за състоянието “410”. Това не е пренасочване в истинския смисъл, защото практически на клиента се връща код за грешка (каквито са тези, започващи с “4”). Понеже клиентът не се пренасочва наникъде след посещението, затова и не е нужно да се указва нов адрес. Споменаваме “410” при пренасочванията за пълнота на всички случаи на разместване на съдържание.

Това са най-разпространените. Иначе има и “300” (multiple choices — сървърът дава списък с адреси и браузърът трябва да избере къде да отиде), “304” (not modified — указва, че обектът не се е променил и съответно браузърът може да реши да полза локално кешираното копие), “305” (use proxy — указва, че търсеният обект трябва да бъде достъпен през посредник, чийто адрес дава също в отговора), “307” (temporary redirect — вариация на “302”, който прави практически същото).

Начин за настройка

Начините за указване на пренасочване са, общо взето, три — през сървъра, през програмния език или през крайния HTML-код.

Настройката през сървъра може да бъде направена или във файла за настройки или, ако нямате достъп до него (например ползвате виртуален хост на споделен хостинг) през файла .htaccess в съответната директория. Синтаксисът е следният:

за постоянно пренасочване
Redirect 301 /old-path.html  http://example.com/newpath.html
или
Redirect permanent /old-path.html  http://example.com/newpath.html
или
RedirectPermanent /old-path.html  http://example.com/newpath.html

за временно пренасочване
Redirect 302 /old-path.html  http://example.com/newpath.html
или
Redirect temp /old-path.html  http://example.com/newpath.html
или
RedirectTemp /old-path.html  http://example.com/newpath.html

Има и по-сложни комбинации с условното RedirectMatch, което приема като първи аргумент регулярен израз, с който можете да пренасочите наведнъж цяла група приличащи си адреси в сайта ви.

Пренасочването през програмния език представлява извикване на функцията в езика, която изпраща HTTP-заглавка към клиента, съдържаща код за пренасочване. Например ето как става за PHP:

за постоянно пренасочване
header(“HTTP/1.1 301 Moved Permanently”);
header(“Location: http://example.com/newpath.html”);

за временно пренасочване
header(“HTTP/1.1 302 Moved Temporarily”);
header(“Location: http://example.com/newpath.html”);

и т.н. Важно е тези редове да се сложат най-отгоре, в началото веднага след “<php”, защото заглавки трябва да се изпращат винаги преди съдържанието. И ако страницата ви даде някакво съдържание и чак след това заглавка, получава се грешка и търсеното пренасочване не става. Отново, ако не се спомене изрично кой е кодът, по подразбиране сървърът ще изпрати “302”, временно пренасочване. Настройката за временно пренасочване е полезна, когато съдържанието наистина е на друго място само временно. Това подсказва индексиращите машини да продължават да следят стария адрес, но временно да насочват а съдържанието към новия. Ако обаче местите наистина за постоянно адреса, грешка е да се ползва 302 (което е по подразбиране) вместо правилното 301.

Пример с Perl през CGI:
#!/usr/bin/perl
print “Status: 301 Moved Permanently\nLocation: http://example.com/newpath.html\n\n”;

или:
#!/usr/bin/perl
print “Status: 302 Moved Temporarily\nLocation: http://example.com/newpath.html\n\n”;

При другите езици, когато се използват през CGI, нещата са подобни. Ако се използва някакъв фреймъурк, като Django или Rails, най-често има готови класове за пренасочване или за връщане на кратък отговор, в който изписваме като текст съобщението за пренасочване. Винаги важното е, че такива отговори трябва да се връщат към уеб-клиента преди всякакво друго съдържание. Общо взето, при пренасочванията всяко следващо съдържание не е важно и се пренебрегва, защото при правилно задаване на пренасочването клиентът вече се е обърнал към другия ресурс и слуша там.

Ако нямате достъп до горните начини или ако не искате да имате общо със сървърни настройки и езици за програмиране, лесно можете да вградите пренасочване в заглавната част на HTML-файл.

<meta http-equiv=”refresh” content=”0; url=http://example.com/newpage.html” />

Стойността на “content” е времето на изчакване преди пренасочването в секунди. 0 означава прехвърляне веднага на новия адрес. HTML-пренасочването е удобно за малки сайтове или отделни страници. За по-мащабни проекти най-добре използвайте описаните по-горе други начини.