Блог вебмастера

После четырёх бета-версий наконец вышел релиз. Как заявляют разработчики, теперь Thunderbird быстрее, безопасней и гибче.



Основные новшества:

1) вкладки;

2) новый, более быстрый поиск;

3) новая архивная папка для более удобной организации;

4) различные усовершенствования пользовательского интерфейса (упрощённая главная панель? новый поисковый виджет, новый мастер аккаунтов, менеджер активности и т.д.);

5) 49 доступных переводов.



Новость на официальном сайте

Полный перевод чейнджлога на opennet



Подробнее:

Обновился отличный Twitter-клиент Mixero (к слову, теперь уже не только Twitter) до версии 0.52. Среди основных нововведений стоит отметить:

• Переход в стадию открытого Beta-тестирования. Теперь не нужно никаких инвайтов.
• Поддержка Twitter-списков
• Поддержка Facebook
• Улучшение производительности, багфиксы, и много прочих мелочей

Для пользователей Mixero, пожалуй, на этом можно закончить чтение. Тем же, кому интересно, почему он отличный (а возможно даже и лучший), и хочет ознакомиться с его возможностями — прошу под хабракат.

Релиз примечателен тем, что IntelliJ IDEA выпущена в двух редакциях — Community Edition и Ultimate Edition.

Множество раз встречаюсь с мнением что пассивная XSS уязвимость не представляет большой опасности и беспокоиться по этому поводу особо не стоит. И несмотря на то, что отчасти это действительно так(если сравнивать с другими, более катастрофическими ошибками), возможность внедрения своего кода на уязвимый сайт, даже требующая существенных дополнительных действий по обману пользователя может привести к серьёзным последствиям, в частности к возможности полностью перехватить дальнейшие действия пользователя.

Сегодня галерея расширений Google Chrome открыта!



Но приятное на этом не заканчивается, так же стала доступна Beta версия Chrome для…

Поработав некоторое время в ОС Linux, я настолько привык пользоваться репозиториями, что, вернувшись обратно в Windows, был буквально в шоке, что для того, чтобы добавить новую программу, надо было сначала найти ее в интернете, загрузить дистрибутив, и только затем, ответив на кучу вопросов, установить ее. При этом, как мы все знаем, программу надо скачивать только с официального сайта, иначе легко нарваться на вирус.



Дальше, предположим, я поработал некоторое время с программой, которая мне понравилась и захотел ее купить. Что мне нужно сделать? Естественно: Menu->About->Buy-> Сайт программы. Здесь читать, куда и как переводить свои деньги, как принять лицензионный ключ после перевода. Так для каждой программы. Не думаете ли вы, что из-за муторности процесса покупки, автор приложения теряет огромную часть покупателей? Насколько ленивы Вы? Лично мне практически всегда проще найти бесплатную альтернативу данной программе (в 95% случаев она есть), чем тратить свое время (заметьте, не деньги!) на оплату лицензионного ключа на приложение. Дело отнюдь не в деньгах, мне абсолютно не жалко $20-30 за хорошо сделанную программу. Мне жалко своего времени.

Прощай Компьютерра. Лучший ИТ журнал когда-либо издававшийся закрывается. Пусть эстафету подхватят сильнейшие.

Сергей Вильянов, главный редактор сайта Компьютерра-Онлайн, на форуме Helpix.ru объявил о выходе последнего номера бумажной «Компьютерры».

Номер выйдет 15 декабря, в нем будут собраны «прощальные статьи всех заметных людей, когда-либо там работавших». В дальнейшем журнал выходить не будет.

История забавная и поучительная.



У нас 2 юридических лица. В одном я директор, в другом заместитель и не контролирую напрямую банк. Второе мы постепенно закрываем, денег на нем нет. Эта мелочь косвенно послужила причиной ситуации, о которой я хочу рассказать.



Год назад фирма А пыталась заказать сайт. Сайт большой, дорогой и сложный, поэтому все тянулось невероятно медленно. В итоге заказали для начала только проектирование сайта. Был составлен договор на написание ТЗ. Исполнителем была организация, где я зам.директора. Заказчик был мутный и медленный, однако все же договор был согласован и мы стали ждать предоплату. Заказчик — ОАО, поэтому каждый платеж проходил долго и ждал многих подписей.



Ждали месяца полтора, договорившись что контактер от заказчика мне позвонит.

Когда-нибудь, пользуясь поиском в интернете, мы не будем задумываться о языковых барьерах. Не потому, что все станут говорить на эсперанто, а потому, что  вся нужная информация будет доступна на родном языке.  Пока же мы делаем первые шаги в том, чтобы стереть границы в многоязычном мире  -  с помощью технологии автоматического перевода  компании ПРОМТ.

Предлагаем всем желающим стать  первопроходцами и поучаствовать в тестировании перевода веб-страниц.  В результатах поиска Яндекса рядом с заголовками зарубежных сайтов такие первопроходцы увидят ссылку «перевод». Кликнув на нее, можно увидеть переведенную на русский язык веб-страницу.  

OAuth — популярный протокол, который позволяет социальным сервисам интегрироваться между собой и дает безопасный способ обмена персональной информацией. OAuth может связать между собой 2 сервиса, каждый из которых имеет свою пользовательскую базу — именно их я в данном случае называю «социальными». Когда начинаешь работать с OAuth, первое ощущение — что протокол весьма сложен и избыточен. В этой статье я попытаюсь объяснить основы OAuth человеческим языком.

Пример кросс-авторизации

Вернемся в 2005-й год и представим, что мы пишем социальную сеть. В ней имеется форма импорта контактов из адресной книги GMail. Что нужно для доступа к контактам GMail? Конечно, логин и пароль от ящика. Но если мы попросим ввести их на нашем сайте, пользователь заподозрит неладное. Где гарантия, что мы не сохраняем на сервере введенные пароли? Поэтому нам хочется, чтобы пароль вводился только на сайте GMail, и после этого доступ к контактам через API GMail предоставлялся нашей социальной сети (возможно, на время).

Договоримся о терминах.

• Consumer: потребитель; скрипт обработки формы импорта контактов в социальной сети.
• Service Provider: поставщик данных; GMail, содержащий в себе данные адресной книги, интересные для Consumer-а.
• User: пользователь, имеющий аккаунт как у Consumer-а, так и у Service Provider-а.
• Protected Resource: личные данные; контакты из адресной книги на GMail (т.е. ресурсы Service Provider-а).
• Provider API: API GMail, позволяющий любому скрипту получить контакты из адресной книги GMail.

Задача OAuth — сделать так, чтобы User имел возможность работать на сервисе Consumer (в соцсети) с защищенными данными Service Provider-а (GMail), вводя пароль к этим данным исключительно на Service Provider-e и оставаясь при этом на сайте Consumer-а. Не так уж и сложно, верно?

Чем OAuth отличается от OpenID?

OAuth часто называют «протоколом для роботов», в отличие от OpenID — «протокола для пользователей». Не путайте их!

1. OpenID — протокол для ускоренной регистрации. OpenID позволяет пользователю без ввода пароля получить аккаунт на каком-либо сервисе, если он уже зарегистрирован где-то еще в интернете. (И потом можно без ввода пароля входить на сервис, будучи авторизованным «где-то».) Например, если у вас есть аккаунт на Яндексе, вы сможете «входить» с его помощью на любой сервис, поддерживающий OpenID-авторизацию.
2. OAuth — протокол для авторизованного доступа к стороннему API. OAuth позволяет скрипту Consumer-а получить ограниченный API-доступ к данным стороннего Service Provider-а, если User дает добро. Т.е. это средство для доступа к API.