brainfucker
0
А по какому параметру данный хакатон крупнейший?
brainfucker
–2
«Но! Как я уже писал выше, если HTTP Refferer не передать совсем, то мы получим нормальный ответ. Я думаю, так было сделано по двум причинам:» – это сделано потому, что refferer не передается для https сайтов
brainfucker
–6
Не вся информация доходит, до разработчиков, просто представьте количество тикетов для техподдержки, сейчас ведется редизайн, который исправит подобные несерьезные косяки, там архитектурно система слоев не очень правильно написана, ее переписать нужно.
brainfucker
–8
Мы работаем над исправлением тех уязвимостей, информация о которых доходит до нас, только с открытием программы на h1 у мы начали налаживать правильный подход для получения информации о них. А вы критикуете не разобравшись. Мы открыли информацию о выплатах на h1, при этом на сколько я знаю среди того что мы обработали – ничего с реальным применением не прислали (но большую часть заявок мы пока не успели обработать), но выплатили уже 2000$, что не может считаться жлобством со стороны ВК как ни крутите
brainfucker
–15
Откуда информация о том, что уязвимости не нужны и что ВК не готовы платить за них, неужели вы думаете, что это то, на чем у нас есть желание экономить, особенно учитывая то, что для компании данные суммы не являются большими?

Дело в том что налетела куча мудаков и начала клянчить деньги либо за мелкие проблемы, за которые станно ожидать больше 100$ либо за баг который был давно, и о котором репортило в разное время человек 100, потому что он вылез гдето на форуме, что теперь мы всем должны всем школьникам способным перепостить запись с форума в интерфейс поддержки по 10000$ выплачивать, серьезно?
brainfucker
–19
Перешел на сайт автора данной статьи, bluzir.me/blog/2%27 как такой человек имеет право тут чтото писать?
brainfucker
+7
Нашедшему уязвимость была предоставлена возможность вывести голоса, например получив деньги на банковскую карту.
brainfucker
+1
В любом случае это маргинальный клиент, оценивать безопасность по нему просто неадекватно.
brainfucker
+37
Поверьте, Вам не было бы интересно узнать об архитектуре проекта с программной точки зрения =))
brainfucker
+18
Нет это лишь часть набора наших инструментов разработки, но уверен, что это действительно большой вклад в развитие OpenSource
brainfucker
+28
Нет, от ООП было решено полностью отказаться еще во времена использования обычного PHP по соображениям производительности
brainfucker
0
на счет предложения выше — безусловно лучше чем ничего, но по опыту могу сказать что очень многие сайты будут говорить пользователю что он не может авторизоваться пока не поставит галочку (картинка с проставленной галочкой). что в итоге перевернет все в чуть менее тривиальную но такую же рутинную процедуру, так как это будет на половине сайтов пользователь привыкнет и начнется хаос и анархия, хотя попробовать так сделать я бы не отказался. Основной вопрос который останавливает – «зачем», если для связи с пользователем – то это скорее плохо чем хорошо, очень не хочется чтобы личка пользователей превратилась в помойку для спама чем для многих стал email. Любой нормальный интернет магазин кроме информации о заказе будет еще и рекламу новых товаров и акций рассылать.
brainfucker
0
Замечание здравое (я о сабже в целом), но очевидно что если мы просто разрешим досуп ко всему апи всем приложениям — начнется хаос и анархия, ведь тогда можно будет смело писать под формой авторизации на своем сайте "* авторизовываясь через ВКонтакте я соглашаюсь разослать всем своим друзьям приглашения на этот сайт". Поэтому я считаю что доступ к личным сообщениям (и другим методам аналогичного уровня приватности) вэб приложениям мы не дадим. На счет примера выше, со связью с пользователем — это должно быть реализовано как-то иначе без доступа к личке. FB решил эту проблему отдавая email. Со временем и мы тоже сможем так делать, (когда процент пользователей для которых email является логином существенно упадет).

В завершение хочу привести небольшой пример того на сколько все плохо в мире: многие сервисы для того чтобы обходить обсуждаемое ограничение просили скопировать токен из адресной строки в специальную форму. Во сновном так делали сервисы для управления пабликами, и создания расписания постов там. Так вот нам пришлось вставить предупреждение в blank.html, так как даже эти честные на первый взгляд сервисы, пользователи которых являются довольно прошаренными и понимают что к чему — злоупотребляли спамом через полученные токены.
brainfucker
0
Все функции camelСase-ом а все лэнги содержат _ поэтому увы нет. А с глобальными переменными все работает чуть быстрее, особенно в старых браузерах… Этот подход позволил работать чуть быстрее конкурентов несколько лет назад.
brainfucker
0
В книгах про js рассматривается немного другой кейс в плане глобальных переменных, а в данном случае — это лэнги для шаблонизации.
brainfucker
0
ВК, для новых приложений теперь возвращаем ошибку, для старых дополнительные поля error и info. Спасибо за информацию.
brainfucker
+6
А я жду дня когда ведомости перестанут писать всякий бред, ведь на ВК сейчас дневная посещаемость около 30 млн, и день когда эта цифра обогнала аудиторию Первого был достаточно давно.
brainfucker
+1
Кривое время на серверах исключено, проблема исключительно в неправельном времени стоящем на компьютере пользователя, при этом пользователь может даже и не догадываться что у него неправельное время, так как у него просто может стоять неправильная таймзона а время выглядеть правельным. Поправили, теперь кука выставляется по относительнму от текущего на клиенте времени, но expire при этом старый, так как может использоваться разработчиками для использования на своих серверах.
brainfucker
+1
Оригинальная цитата такая: Предпочтение все-таки отдается проектам, которые представляют уже готовые прототипы или хотя бы дизайн-макеты.
brainfucker
+4
Да бросте Вы, совершенно очевидно, чего автор не понял. Об этом говорит пример с фиббоначи, как бы вы не старались, как бы не параллелили, если у вас одно ядро — Вы можете хоть миллион тредов наплодить, но быстрее всего задача будет решена последовательным выполнением, как в ноде, треды принесут лишь оверхэд, а если ядер несколько — нужно поднимать несколько инстансов ноды. Под неблокирующей архитектурой понимается лишь неблокирование ввода вывода, про CPU никто не говорит.
brainfucker
+3
Приложение было заблокировано именно по этой причине.
brainfucker
–2
Да ну ссылку легко можно привязать к ip адресу как это сделано с сылками на аудиозаписи и документы, другое дело что такая привязка для фотографий доставит куда больше проблем для пользователей с динамическими ip чем незащищённость прямых ссылок.
brainfucker
0
Да, кстати на сколько я помню был параметр, включающий Crankshaft.
brainfucker
+3
Я в таких случаях просто использую таблицу. Несмотря на то, что идеалогически это куда более худшее решение, оно значительно быстрее рендерится в браузерах.
brainfucker
0
как правило можно просто запускать несколько экземпляров а балансировать на nginx
brainfucker
0
Стив не одобряет скриншот=)
brainfucker
0
Тем не менее это тоже весма полезно, так как позволит осуществить более быструю коммуникацию между воркерами, как если не ошибаюсь и сделано в эрланге…
brainfucker
+1
по 8 воркеров на машине работают более менее нормально, хотя недавно был нападок спамеров, которые сильно мучали сервера (пришлось усилить флудконтроль)

Ещё приходится перезагружать воркеры… это делается плавно, вечером запускаются новые а старые перестают принимать новые соединения, утром старые убиваются…

Сейчас примерно такая картина:
Cpu(s): 19.2%us, 0.7%sy, 0.0%ni, 79.1%id, 0.0%wa, 0.5%hi, 0.4%si, 0.0%st
heap ~ 113076624 на воркер

Ситация с GC видится совсем не смертельной, за удобство нужно платить. Иногда задержки ощущаются но тоже не смертельно.
brainfucker
0
Да, пожалуй эти две проблемы являются самыми заметными в серверном коде… Когда израсходовано много оперативной памяти то GC начинает есть много CPU и замедляет приложение.
brainfucker
+1
Какраз F-Spot убунту уже выпилила в 10.10 =)
brainfucker
+4
Кстати, забыл сообщить о том, что появилась группа с трансляцией Хабра vkontakte.ru/habr Некоторым разработчикам удобнее получать обновления через свою ленту статусов.
brainfucker
0
Очень интересно, страшно интересно было бы взглянуть на результат CLang-а в даной ситуации
brainfucker
0
Стоит человеку переходящему с PHP/Perl не понимая того заюзать блокирующую функцию вне инициализации, как его проект начнёт дико медленно работать, и он будет во всю ругаться и кричать что Нода медленная, поэтому мне кажется Важно чётка Дать разработчику понять, что блокирует выполнение, а что нет.
brainfucker
0
Я за переименование… Всё блокрующее в Ноде стоит помечать окончанием Sync а не наоборот…
brainfucker
0
Скорее всего каждый запрос в отдельном треде
brainfucker
0
Больше всего волнует вопрос отказоустойчивости в Mongo, гдето слышал что достаточно пары reset-ов чтобы пришлось мучительно восстанавливать базу, а ведь хочется такой-же стойкости как у innoDB! Может кто-то может поделиться опытом?
brainfucker
0
Запрещённое видео в контакт тожепруф.