Какво ново?

Доста са промените, но най-голямо впечатление правят премахването на перманентното изтриване на публикации/страници/файлове. Вместо това, системата вече има кофа за боклук (Trash). Нещо като архив. Съдържанието от Trash-a вече може да бъде изтрито перманентно, при задаването на съответната команда.

Поработили са и върху медията. В WordPress 2.9 разполагате с редактор за изображения – можете да си ги връткате, флипвате, кропвате, както самите картинки, така и техните thumbnails. Всяка една промяна се записва във version control-a, а ако решите, винаги можете да възстановите оригиналното ъплоуднато изображение. Яко!

Също така качването на embed съдържание (флашове, клипчета от youtube) също е подобрено и би трябвало да става много лесно (още не съм го тествал), да е нещо от сорта на [еmbed]http://www.youtube.com/watch?v=2dgxKdcpS38&feature=player_embedded[/embed]. Дано флашовете да се показват и валидирано в HTML кода.

Пълен списък с промените можете да видите тук.

Забелязвам, че стиловете на бутоните са леко променени (<input> елементи), и се различават от линковете с формата на бутон (<a> елементи). Ще потърся защо така, може да е нарочно, може и да не е, в предварителните бета версии това не го забелязах.

П.П. Днес баща ми има рожден ден, да е жив и здрав!

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

И всичките са пуснати от различни IP-та, разбира се

Междувременно пък са пуснали и Release Candidate на версия 2.8.1. Т.е. съвсем скоро можем да очакваме и официалната версия, примерно към края на седмицата, така си мисля. В новата версия няма да има нови неща, а само bug fixes.

Забелязвам малко проблеми с последната версия на WordPress – 2.8 и плъгина за мултиезична поддръжка – qtranslate. След като активирам плъгина, системата ме пренасочва към формата за логин и дори да се логна с правилните име и парола, отново и отново ме препраща към тази форма и така един безкраен цикъл. Писах на автора на qtranslate, но засега нямам резултат.

Подобренията са доста сериозни и много ме радват! Браузърът е чувствително по-бърз! Прословутият вече нов JavaScript енджин TraceMonkey работи с пълна пара и резултатите вече се забелязват – JavaScript performance-a на новият 3.5 е доста по-добър в сравнение с неговия предшественик. Е, Мозила имат още малко да потичат докато настигнат Chrome и Safari по този критерии, но важното е, че са на прав път

Друго важно подобрение във Firefox 3.5 е новата версия на Gecko енджина (1.9.1). Направени са доста оптимизации по платформата за по-бързо рендване и визуализация на съдържанието. Освен това вече се поддържат и всички CSS селектори! Направих CSS селектор тест на новия 3.5 и предшественика 3.0.11. Резултатът: 36 от 43 поддържани селектора от 3.0.11 и 43 от 43 за 3.5 От общо 578 теста, 3.0.11 минава 373, а 3.5 ги минава всичките 578. Страхотно!

Освен това, новият Firefox се справя почти отлично и с Acid 3 теста. 93 от 100 точки, срещу 72/100 за Firefox 3.0.11. Скриин от тестовете можете да видите тук (отляво са резултатите на FF 3.0.11, отдясно на 3.5):

Друго интересно около новата версия е поддръжката на HTML 5 <video> и <audio> елементи, както и Native JSON. Тук можете да видите всичко останало.

Ако искате да инсталирате паралелно новата и стари версии на Firefox, които да са независими една от друга, тук е описано как става това.

Ами това е. Новата версия определено ми харесва със своята бързина. Що се касае до използването на компютърните ресурси, гледам няма някаква оптимизация – браузърът продължава да си гълта яко рамчица . Ама това да му е проблема – ще ъпгрейдваме и така . Спирам да пиша, защото искам да се кефя на Firefox 3.5

Защита на конфигурационния файл (wp-config.php)

Най-важният файл от системата. В него се съдържа информацията, необходима за връзка към базата данни. Сами разбирате колко е важно да не бъде разбит от външно лице.

Ако инсталацията на WordPress е директно във вашата /public_html директория, преместете wp-config.php във root директорията на сървъра. Т.е. изнесете го извън /public_html папката (тази, в която качвате файловете за вашия уебсайт (може да се казва /www)). Главната (root) директория на сървъра никога не е достъпна директно през HTTP от браузера и това допълнително ограничава достъпът до всеки файл, записан там. Няма нужда да се притеснявате, че файлът wp-config.php е преместен – WordPress ще си го намери

Ако поддържате няколко инсталации на WordPress, няма как да преместите всичките конфигурационни файлове на root директорията, тъй като те са с едно и също име. В този случай просто ги защитете с един .htaccess файл:

<files wp-config.php>
Order allow,deny
deny from all
</files>

Така сървърът ще реже всякакъв достъп до файла през HTTP.

Измислете достатъчно сложни и дълги Security Keys

Тези Security Keys представляват константи, които се задават във файла wp-config.php и хич не са за пренебрегване, тъй като те генерират различни и уникални хешове, които се добавят към паролите, куукитата, сесиите, и правят системата доста по-трудна за хакване. Въпросните ключове са AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY и NONCE_KEY. Общо взето стойностите им трябва да изглеждат горе-долу така:

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh');
define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8');
define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t');

Не се стряскайте от стойностите, НЕ ТРЯБВА ДА ГИ ПОМНИТЕ! Пак казвам, това са стрингове, които се използват при хешването на пароли и бисквитки, следователно колкото по-дълги и сложни са, толкова по-добре за вас . Ако не можете да си измислите ваши, WordPress ви предлага API, което ще ви помогне, но лично аз ви съветвам да си напънете малко мозъците и да си ги измислите сами. Ъ, кви мозъци бре, просто поскачайте безразборно няколко секудни по клавиатурата и сте готови

Защита на базата данни

Представката за таблиците на WordPress е дефинирана в конфигурационния файл (wp-config.php) и по подразбиране е "wp_". Просто си измислете друга, по дяволите

Защита на администраторския акаунт

При инсталацията на WordPress автоматично се създава администраторски акаунт с име admin и случайно генерирана парола. За съжаление, системата не позволява преименуване на акаунтите, а не е добре да се оставя това име, тъй като масово опитите за brute force break на администраторски акаунт са с username: admin и просто опитват различни пароли.

Създайде нов акаунт от Потребители, и му дайте администраторски права. Измислите си дълга и сложна парола. Нека символите са повече; нека има главни и малки букви, цифри и знаци от сорта на !, $ и пр. Логнете се с новия акаунт и отново от Потребители изтриите admin акаунта. Ако имате създадени публикации/страници с потребителя admin, то не забравяйте при изтриването му те да се прехвърлят на новия ви акаунт!

А можете и просто директно през базата данни в таблицата users да смените името admin на друго, по ваше желание. Но препоръчвам първия метод, тъй като новият административен акаунт ще дойде с ново ID, т.е. няма да е 1. По-добре така, за всеки случай

Защита на административната директория (/wp-admin/)

Ако се питате има ли начин да се преименува админ папката wp-admin на нещо друго, веднага ви отговарям – няма начин . Името "wp-admin" е хардкорнато, среща се над 100 пъти из файловете. Можете да го смените с един мощен find/replace с любимия ви редактор, но по този начин ще загубите възможността за update на системата. Или при всеки ъпдейт ще трябва отново да сменятте името. Въпрос на преценка, дали ви удовлетворява тоя вариант, или не.

Все пак потърсих информация по въпроса с преименуването. Намерих едно добро "решение" на Michi Kono. Решение в кавички, защото изглежда е работело при версия на WordPress 2.3.* и надолу, но след версия 2.5 не работи. Въпреки това, нека все пак да обясня. Идеята е много добра. Да речем, че вместо "wp-admin", искаме да кръстим администрационната папка "customadmin". Добавят се няколко редирект условия и команди в главния .htaccess файл. Всеки един request, в който се съдържа името wp-admin и НЕ се съдържа GET променливата "YOURSECUREPHRASE" връща грешка, че страницата не може да бъде намерена. Следващото условие е, request в който се съдържа името customadmin да препраща към wp-admin?YOURSECUREPHRASE . По този начин успешно избягваме от условието да бъдем препратени към страница за грешка или несъществуващ файл при всеки request, в който викаме "wp-admin".

Защо не работи в новите версии на WP? Въведен е метод, който проверява REQUEST_URI-то на всеки един php файл от wp-admin папката. Ако файлът не се извиква от /wp-admin/ , т.е. този стринг го няма във REQUEST_URI-то, файлът препраща към страницата за логин. И така се получава един безкраен цикъл.

Ясно, няма как да сменим името на wp-admin към този момент. Как да я подсигурим обаче? Има две неща, които можем да направим.

Защитете директорията на ниво сървър – с .htaccess и mod_access. Създайте един потребител, с достатъчно сложна парола; създайте един .htaccess файл във wp-admin директорията, и един .htpasswd. Във .htaccess пишем:

# път до .htpasswd файла
AuthUserFile /path/to/yoursite/wp-admin/.htpasswd
AuthName EnterPassword
AuthType Basic
require valid-user

Във .htpasswd пишете всички потребители:пароли, които искате да имат достъп до директорията. Всяко потрбителско име се пише на нов ред, следвано от двуеточие (:), и веднага след него криптираната парола.

myuser:$apr1$f3TOu...$MSAsViNERcB.6i3rdPO7/1

Относно криптирането на паролата, ползвайте този онлайн криптиращ инструмент.

Ако сървърът ви поддържа SSL, ползвайте HTTPS за wp-admin директорията. Прави се много лесно, просто добавете define(’FORCE_SSL_ADMIN’, true); някъде във конфигурационния файл (wp-config.php).

Ограничете грешните опити за вход до минимум

По подразбиране, WordPress няма ограничение върху грешните опити за login (вход). По този начин съществува опасност от "счупване" на паролата с brute force. Пускат ви няколко стотин ботове, които непрекъснато опитват различни комбинации от потребителски имена и пароли, идеята е да уцелят правилните и да ви влязат в администрацията. Теоретично, ако username-a и паролата ви са достатъчно сложни, ще им е необходимо доста време да ги уцелят. Нека все пак обаче да ги ограничим

Limit Login Attempts е плъгин, който ще свърши тази работа. Единственото, което трябва да направите, е да го изтеглите и инсталирате. Дори не е необходимо да му пипате и настройките по подразбиране. А те са следните: всяко IP има право на 4 грешни опита, след което IP-то се заключва за 20 минути – време, в което дори да се въведат правилни име и парола, системата няма да даде достъп на това IP. 4 такива заключвания водят до заключване за 24 часа Тези настройки можете да си ги променяте по ваша преценка, разбира се – в администрацията, Options -> Limit Login Attempts.

Плъгинът остранява и друг недостатък на WordPress. По подразбиране, системата дава информация дали само username-a е грешен; ако съществува такова потребителско име изписва, че е грешна паролата. А това е доста ценна информация за недоброжелателите, тъй като те ще знаят кога са уцелили съществуващо потребителско име, и вече следват опити само с пароли. Limit Login Attempts винаги ще връща грешка "Невалидно потребителско име ИЛИ парола"

Направих български превод за този plug-in, можете да го изтеглите: limit-login-attempts-bg_BG

Защита на папките и файловете. Права

Последно по ред, но не и по важност. Даже трябваше с това да започна. Изобщо не подценявайте правата, защото може да имате сериозни главоболия, и всички неща, изписани по-горе да се окажат безполезни!

Във файловите системи файловете и директориите имат различни права в зависимост от това кой потребител може да ги чете, да ги модифицира/трие/пише в тях, и да ги execute-ва. Пример за потребител – FTP user-a, с който се логвате, е един потребител; Apache сървърът е друг и т.н. Уверете се, че всички WordPress директории имат пълни права само за техния създател -rwxr-xr-x (CHMOD 755). Това означава, че само потребителят, създал папката, има пълни права да пише и execute-ва. Групите и публичните потребители нямат права за писане. Нека всички файлове имат права -rw-r--r-- (CHMOD 644). Тези права се задават посредством FTP клиент, с командата CHMOD. Повече информация относно правата.

Добре, ами какво става с wp-content/uploads директорията? Не мога да качвам файлове!

Масова практика е да се задават пълни права на wp-content/uploads директорията (CHMOD 777) – ГРЕШКА! 777 означава, че всеки, АМА АБСОЛЮТНО ВСЕКИ може да записва в тази директория, и бедна ви е фантазията какви гадории могат да ви хвърлят там! Ако ъплоуд директорията ви има права 755 и не можете да качвате/изтривате файлове през админ панела на WordPress, то значи най-вероятно сте я създали с вашия FTP потребител. 

Как да поправим нещата:

1. изтривате папката uploads
2. давате пълни права на wp-content папката (CHMOD 777)
3. отивате в админ панела на WordPress и upload-вате някакъв файл, няма значение какъв, към публикация или страница, без значение
4. връщате старите права на wp-content директорията (CHMOD 755)

Това е всичко. При качването на файл WordPress ще потърси wp-content/uploads директорията. Тя не съществува, следователно системата ще се опита да я създаде. Родителската директория wp-content има пълни права за писане и това не е проблем. След това връщаме старите права, но автор на uploads директорията вече е сървърът (apache), и само той има пълни права над нея и всички файлове/директории вътре. По този начин получавате пълна фунцкионалност на системата, включително да качвате и триете файлове през контролния панел, и в същото време директорията  е защитена от качването на файлове-вредители отвън.

Ако с FTP клиента сте качили някакви файлове преди това – сори, но ще трябва да ги качите пак. Това е положението. Вариант е да си напишете малък php скрипт, който да обходи uploads директорията и да направи пълно копие на всички папки и директории вътре в нова директория, uploads2 да речем. След копирането изтривате uploads папката, и новата uploads2 я преименувате на uploads.

Заключение

Спазвайте всички изброени дотук неща и спете спокойно А, да, и не забравяйте редовно да си обновявате WordPress до последна версия

По темата (на английски): Hardering WordPress, Changing File Permissions

Промените са доста, но са насочени основно към административния интерфейс. От блога на Марио разбрах, че има подобрения по скоростта – честно казано не бях забелязал, но съдейки по организацията на javascript-а в админ частта (доста по-малко кънекции и код като цяло), определено има положителен ефект.

Подобрили са възможностите за организация на Dashboard-a, както и страниците за преглед на Публикации и Страници. Развили са доста Theme и Plugin браузерите. Демо можете да видите на българския WordPress сайт. Или можете направо да си дръпнете системата

Изобщо, наблегнали са на подобрения, ориентирани към блогърите, които не се занимават с web development. От гледна точка на WordPress като платформа, подобренията са незначителни.

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

Вече се работи по версия 2.9 и 3.0. Очаквам да видим сериозни подобрения във трета версия, най-вече откъм ядрото на системата. Моя отдавнашна мечта е да добавят възможност името на админ директорията да може да се променя (за още по-голяма сигурност). Тези дни четох доста по въпроса със сигурността на WordPress и за това как да я подсигурим допълнително. Стига да ми остане време, до края на седмицата ще драсна един пост да споделя малко tips & tricks

Днес е и рожденния ден на Владо, да е жив и здрав!

Всичко точно, но (естествено) не работи във факания Интернет Експлорер. Натъкнах се на ето този пост. Оказа се, че за да проработи формата във браузера на Майкрософт трябва да се добави и още един атрибут: encoding="multipart/form-data".

Аз все пак реших да филтрирам браузера и да добавям този атрибут само за IE.

$("form#upload-form").attr("enctype", "multipart/form-data");
if ($.browser.msie)
    $("form#upload-form").attr("encoding", "multipart/form-data");

От Microsoft смело се изказват, че IE8 успешно се конкурира по бързина, сигурност и поддръжка на уеб стандартите с останалите браузери, че даже бил и по-бърз. Ще видим! С нетърпение чакам резултати от тестове.

Но контакт листата ми постепенно започна да се стопява. Стигна до там, че дневно онлайн са не повече от 10 човека. По напълно различен начин стои въпросът при конкурента Skype – дневно в контакт листата ми са онлайн повече от 50 души. И така, бях го решил от доста време, и този петък го направих – uninstall.

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