О безопасности в Meteor и не только (часть 1)

Для разработки приложений фреймворка Meteor существует некоторое число приемов и средств, предназначенных для обеспечения безопасности. В первой части мы поговорим о более известных вещах — скрытии серверной части кода, пакетах autopublish / insecure, скрытии полей коллекций при публикации и встроенной системе учетных записей, заглянув внутрь коллекции Meteor.users. Во второй — про loginToken, выдаваемый клиенту, правила allow/deny при модификации базы данных клиентом, доверенном и недоверенном коде, серверных методах, HTTPS, пакете force-ssl и пакете browser-policy (Content Security Policy и X-Frame-Options), встроенном механизме валидации данных (функция check() и пакет audit-arguments-check).

Все, описанное ниже, применимо к текущей версии Meteor 0.7.0.1 с установленным Meteorite. Кстати, если примеры этой статьи не будут работать в более новой версии Meteor, с помощью Meteorite примеры этой статьи также можно будет посмотреть, указав при запуске ключ —release:

$ mrt --release 0.7.0.1 

Скрытие серверной части кода

Начнем, пожалуй, с самого простого — разнесения клиентской и серверной частей кода. Хотя Meteor допускает совместное использование кода клиентом и сервером, делать так имеет смысл только при реальной необходимости. Кроме структурирования самого проекта, которое так или иначе понадобится по мере роста его объема, и сокращения объема данных, передаваемых клиенту, это позволяет скрыть код серверной части.
Подкаталоги server, client, client/compatibility, public, private, lib, tests (и файлы main.*) обрабатываются особым образом. Достаточно подробно это описано в документации: docs.meteor.com/#structuringyourapp. Для кода, выполняемого только на сервере предназначен каталог server, файлы из которого не передаются клиенту. Аналогичным образом, код из файлов в каталоге client не загружается на сервер.
Некоторая часть кода, как, например, объявления коллекций, должна быть доступна и клиенту и серверу. Такой код можно размещать в подкаталогах с любыми названиями, отличными от зарезервированных (также можно его разместить в lib, разница в том, что файлы из этого каталога загружаются раньше других).
В рамках этого примера мы будем размещать объявления коллекций в подкаталоге collections.
Создадим новое приложение:

$ mrt create littlesec 

И удалим автоматически созданные файлы:

$ cd littlesec $ rm littlesec.* 

Создадим подкаталоги server, client, collections. В collections добавим файл test.js с объявлением тестовой коллекции:

Test = new Meteor.Collection('test'); 

Собственно, проект уже можно запустить:

$ mrt  

И открыть в браузере: localhost:3000
Мы увидим только пустую страницу, но объект Test, пусть тоже пустой, уже будет доступен из консоли:

> Test.find().count()   0 

Добавим файл home.html в подкаталог client:

<head>   <title>littlesec</title> </head>  <body>   {{> home}} </body>  <template name="home">   {{#each test}}     <li>       <ul>_id:'{{_id}}' name:'{{name}}' value:'{{value}}'</ul>     </li>   {{else}}     <p>Collection Test is empty</p>   {{/each}} </template> 

И home.js:

Template.home.test = function() {   return Test.find({}); } 

В подкаталог server — файл startup.js:

 Meteor.startup(function(){   if (!Test.find({}).count()) {     var testValues = [       {name: 'First', value: 1},       {name: 'Second', value: 2},       {name: 'Third', value: 3}     ];     testValues.forEach( function(testValue) {       Test.insert(testValue);     });   } }); 

Теперь тестовая коллекция доступна как клиенту, так и серверу, причем код сервера клиенту не передается. Поле _id — идентификатор базы данных, автоматически генерируемые при вставке новой записи.

На данный момент коллекция доступна абсолютно всем как на чтение, так и на запись, что можно проверить из консоли:

> Test.findOne({}) 

И:

> Test.insert({name: 'Fourth', value: 4}) 

Убираем пакеты autopublish / insecure

Полный доступ к объявленной нами коллекции мы получили благодаря подключенным по умолчанию к проекту при создании пакетам autopublish и insecure. Первый из них «публикует» все существующие на сервере коллекции, второй — дает полные права на их изменения. Это существенно облегчает знакомство с Meteor и быстрое прототипирование, но, разумеется, неприемлемо в реальной жизни, поэтому:

$ mrt remove autopublish  $ mrt remove insecure 

Объект Test в браузере по-прежнему доступен, однако данных больше нет:

> Test.find().count()   0 

Теперь, чтобы в штатном режиме, без autopublish, клиент получил доступ к серверным данным, сервер их должен опубликовать, а клиент — подписаться.
Добавим в файл server/startup.js публикацию коллекции (ее можно поместить как вне функции, добавляемой Meteor.startup(), так и внутри неё; разница будет в моменте создания публикации — важно, чтобы к этому времени публикуемая коллекция уже существовала):

Meteor.publish('test', function() {     return Test.find();   } ); 

Если коллекцию опубликовать в то время, как пакет autopublish еще подключен к проекту, при старте Meteor будет выведено предупреждение об этом:

I20140131-11:36:07.343(4)? ** You've set up some data subscriptions with Meteor.publish(), but I20140131-11:36:07.388(4)? ** you still have autopublish turned on. <..> 

В файл client/home.js добавим соответствующую подписку:

Template.home.test = function() {   return Test.find({}); } 

Теперь данные в браузере опять появились, однако прав на их изменение больше нет:

> Test.insert({name: 'Fifth', value: 5})   "BDgB258TovmqS7YbY"   insert failed: Access denied  

Обратите внимание, что запись сначала вставляется в локальную коллекцию, возвращается ее идентификатор («BDgB258TovmqS7YbY»), и эта запись отображается в браузере, затем с сервера приходит уведомление об ошибке, и вставка в локальную коллекцию «откатывается». Отображение в браузере происходит благодаря механизму компенсации задержек, а ошибка появляется из-за проверки правил allow/deny (о них — чуть позже); без пакета insecure изменения по умолчанию запрещены.

Скрытие полей при публикации

Коллекцию не обязательно публиковать полностью. До сих пор отображались все поля из серверной коллекции. Можно, например, скрыть поле _id, это ограничит возможность манипуляции данными, так как со стороны клиента для изменении данных необходимо указывать идентификатор записи (см.также ограничение изменения данных по_id), либо другие поля, как, например, это реализовано в коллекции Meteor.users (см.ниже):

Meteor.publish('test', function() {     var projection = {_id: 0, value: 1};     return Test.find({}, {fields: projection} ); //    return Test.find();   } ); 

Скрыть поле _id таким образом, к сожалению, не получится — вероятно, оно используется для установления соответствия между серверной и локальной коллекциями. В текущей версии это приведет к ошибке, раньше просто возвращало пустую коллекцию.
Разумеется, на объеме передаваемых данных скрытие полей также скажется положительно.

Система учетных записей Meteor

Все сказанное выше применимо к неавторизованным пользователям. А какие возможности появляются, если пользователь авторизован?
Добавим к проекту поддержку системы учетных записей Meteor:

$ mrt add accounts-base $ mrt add accounts-ui $ mrt add accounts-google 

Кроме accounts-google есть официальные пакеты для целого ряда провайдеров авторизации, в их числе Facebook, Twitter, Github и другие. Неофициальными пакетами поддерживаются и другие провайдеры, например, Vkontakte.
Используем в home.html готовый шаблон кнопки авторизации пользователя:

{{loginButtons}} 

И currentUser для отображения информации о пользователе:

{{currentUser._id}} {{currentUser.profile.name}} 

И, воспользовавшись пошаговой инструкцией, которая будет выведена при первом нажатии на кнопку, зарегистрируем свое приложение в Google, после чего немедленно сможем авторизовать пользователя.
Добавим пакет для поддержки Facebook:

$ mrt add accounts-facebook 

Затем зарегистрируем второго пользователя.
Учетные записи хранятся в коллекции Meteor.users, но если в браузере мы обратимся к ней, увидим только один документ, хотя пользователей зарегистрировано уже два:

> Meteor.users.find().count()   1 

Дело в том, что по умолчанию (если отключен пакет autopublish — с ним клиенту доступна вся коллекция Meteor.users) у клиента есть доступ только к части полей своей собственной документа:

> Meteor.users.findOne()) {"_id":"8fLXBYpNGLqDwAahg","profile":{"name":"<Имя пользователя>"}} 

Этот же документ доступен через переменную Meteor.user, а его идентификатор — Meteor.userId()

> Meteor.user()   {"_id":"8fLXBYpNGLqDwAahg","profile":{"name":"<Имя пользователя>"}} 

Есть и соответствующий функция (helper) Handlebars currentUser, с помощью которого мы выводим информацию о текущем пользователе.

Если заглянуть в исходники пакета accounts-base, коллекция Meteor.users создается на сервере следующим образом:

Meteor.users = new Meteor.Collection("users", {_preventAutopublish: true});           

И публикуется так:

// Publish the current user's record to the client.                                                      Meteor.publish(null, function() {                                                                                     if (this.userId) {                                                                                                         return Meteor.users.find(                                {_id: this.userId},                                                                                               {fields: {profile: 1, username: 1, emails: 1}});                                                              } else {                                                                                                            return null;                                                                                                    }                                                                                                               }, /*suppress autopublish warning*/{is_auto: true}); 

Если пользователь авторизован, this.userId содержит его идентификатор, по которому из базы возвращается поддокумент profile, поле username и поддокумент emails (последние два не заполняются по умолчанию). В противном случае никакие данные не публикуются. Это значит, что авторизованному пользователю по умолчанию доступна только часть полей и только его собственного документа из базы.

Ссылка на изображение пользователя Google из социальной сети хранится в поддокументе services.google.picture, а получить доступ к изображению из Facebook можно, используя идентификатор services.facebook.id. Чтобы получить к ним доступ, их необходимо дополнительно опубликовать, например, так (добавим в server/startup.js):

Meteor.publish(null, function() {   if (this.userId) {     var projection = {       'services.google.picture': 1,       'services.facebook.id':    1,       'services.vk.photo':       1     };     return Meteor.users.find(       { _id: this.userId },       { fields: projection } );   } else {     return null;   } }); 

И ссылку на картинку — в home.html:

  {{#if currentUser.services.facebook}}     <img src="http://graph.facebook.com/{{currentUser.services.facebook.id}}/picture/?type=square"> <!-- small || normal || large || square -->   {{else}}{{#if currentUser.services.google}}     <img src={{currentUser.services.google.picture}}>   {{else}}{{#if currentUser.services.vk}}     <img src={{currentUser.services.vk.photo}}>   {{/if}}{{/if}}{{/if}} 

Выбранные поля теперь доступны клиенту:

> Meteor.users.findOne() {   "_id":"8fLXBYpNGLqDwAahg",   "profile": {      "name":"<Имя пользователя>"   },   "services": {     "facebook": {       "id": "100000783871952"     }   } } 

Вместо того, чтобы явно указывать поля, можно было опубликовать весь документ пользователя, задав projection = {} или поддокумент services, задав projection = { services: 1 }. Однако в этом случае клиент получит явно лишние для него данные, такие как accessToken или loginTokens.
При необходимости отображать информацию о других пользователях, можно опубликовать избранные поля всех документов коллекции, например, добавив к существующим публикациям еще одну:

Meteor.publish(null, function() {   var projection = {     'profile.name': 1   };   return Meteor.users.find(     { },     { fields: projection } ); }); 

Результатом будет объединение всех публикаций, и теперь всем пользователям, в том числе неавторизованным, доступны имена всех зарегистрированных пользователей, а текущему пользователю — дополнительные поля его документа:

Meteor.users.find().fetch() [   {     "_id":"8fLXBYpNGLqDwAahg",     "profile": {       "name":"<Имя пользователя>"     }   }, {     "_id":"kL7Fkuk29ci4vz8q4",     "profile": {       "name":"<Имя пользователя>"n"     },     "services": {       "google":{          "picture":"<ссылка на изображение>"       }     }   } ] 

ссылка на оригинал статьи http://habrahabr.ru/post/211002/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *