Комментарии 21
Для начала нужно получить токен для доступа. [...] необходимо отправить HTTP POST[...] c таким JSON содержимым в теле:
Ауч, почему очередной велосипед вместо OAuth?
lair, спасибо за вопрос!
Если коротко, то мы поддерживаем пока только JWT-like подход авторизации API для клиентов, которые владеют паролем напрямую. Например, это используется для мобильных приложений. OAuth для поддержки авторизации третьих сторон в планах. Подробнее про разницу подходов можно почитать здесь: www.seedbox.com/en/blog/2015/06/05/oauth-2-vs-json-web-tokens-comment-securiser-un-api
Если коротко, то мы поддерживаем пока только JWT-like подход авторизации API для клиентов, которые владеют паролем напрямую. Например, это используется для мобильных приложений. OAuth для поддержки авторизации третьих сторон в планах. Подробнее про разницу подходов можно почитать здесь: www.seedbox.com/en/blog/2015/06/05/oauth-2-vs-json-web-tokens-comment-securiser-un-api
Так в OAuth 2 это тоже есть, называется client credentials flow. Зачем велосипед?
lair, Вы действительно правы. OAuth 2 полностью поддерживает этот сценарий. Когда мы внедрим OAuth, он вероятно станет нашим основным механизмом авторизации. На момент разработки текущего механизма стояла задача обеспечить авторизацию только между двумя сторонами. JWT подход решает эту задачу. OAuth 2 также ее решает, но он сложнее в реализации. JWT подход был выбран из-за простоты и скорости разработки.
OAuth 2 также ее решает, но он сложнее в реализации.
Вы хотите сказать, что для node.js нет готовых решений?
Сергей, хочу сказать решения есть. Вот например: github.com/thomseddon/node-oauth2-server. Но для того, чтобы его использовать, нужно как минимум решить проблему с хранением токенов. Мы поддерживаем как MongoDB так и базы данных SQL. Поэтому здесь задача немного усложняется. Т.е. это делается, но на это нужно было бы потратить немного больше времени, чем на JWT. Мы приветствуем любые инициативы относительно развития проекта. Их можно писать прямо сюда: github.com/allcount/allcountjs/issues. Если Вы знаете как можно быстро и просто реализовать OAuth 2, то мы с удовольствием примем от Вас pull request.
[mr.accuracy]На сайте написано, что за 10 минут. ;)[/mr.accuracy]
Заинтересовало, в качестве автогенератора апи для мобильных приложений.
Заинтересовало, в качестве автогенератора апи для мобильных приложений.
jMas, спасибо за обратную связь!
Вы нас поймали! :) Я думаю Максим поделится своими соображениями, где возникает разница на 5 минут.
Рады, что смогли Вас заинтересовать! Для гибридных мобильных приложений у нас также есть интеграция с ionic (http://ionicframework.com/). Если есть вопросы, то мы доступны в чате Gitter: gitter.im/allcount/allcountjs, в группе facebook: www.facebook.com/groups/allcountjs и здесь.
Вы нас поймали! :) Я думаю Максим поделится своими соображениями, где возникает разница на 5 минут.
Рады, что смогли Вас заинтересовать! Для гибридных мобильных приложений у нас также есть интеграция с ionic (http://ionicframework.com/). Если есть вопросы, то мы доступны в чате Gitter: gitter.im/allcount/allcountjs, в группе facebook: www.facebook.com/groups/allcountjs и здесь.
Англоговорящие поймут быстрее, и за 15 все успеют)
Хмм… А вот на Orienteer можно и вообще за 5 минут такое сделать причем вообще не кодируя. Но тема да — интересная… Какие есть ограничения у фреймворка? Т.е. какие задачи гарантировано не стали бы решать AllCountsJS?
DbLogs, здорово! Спасибо за ссылку!
Не рекомендую использовать AllcountJS, где нет работы с БД, т.к. его использование становится бессмысленным. AllcountJS заточен на то, чтобы сделать разработку всего, что связано с CRUD максимально простым не ограничивая возможности эко-системы Node.js. Любые бизнес приложения (CRM например) это по сути своей в основном CRUD и AllcountJS для этого хорошо подходит.
Также мы постараемся раскрыть в ближайших публикациях как применить AllcountJS к продуктовым историям, где есть backoffice. Например, на днях мы запустили zrum.ru — поисковик по наличию мотозапчастей, на который потратили 6 часов работы. Там внутренняя БД запчастей синхронизируется с внешними excel файлами, которые лежат в открытом доступе по URL. При этом из коробки есть возможность вести каталог вручную.
Не рекомендую использовать AllcountJS, где нет работы с БД, т.к. его использование становится бессмысленным. AllcountJS заточен на то, чтобы сделать разработку всего, что связано с CRUD максимально простым не ограничивая возможности эко-системы Node.js. Любые бизнес приложения (CRM например) это по сути своей в основном CRUD и AllcountJS для этого хорошо подходит.
Также мы постараемся раскрыть в ближайших публикациях как применить AllcountJS к продуктовым историям, где есть backoffice. Например, на днях мы запустили zrum.ru — поисковик по наличию мотозапчастей, на который потратили 6 часов работы. Там внутренняя БД запчастей синхронизируется с внешними excel файлами, которые лежат в открытом доступе по URL. При этом из коробки есть возможность вести каталог вручную.
Двойственные впечатления, с одной стороны — довольно любопытно. Хотелось бы так же взглянуть на roadmap и узнать планы монетизации. С другой стороны — лично меня angular смущает, мне нравятся библиотеки попроще. Более того, я не уверен, что вы с ангуляром всё делаете правильно, т.к. на вашем же allcountjs.com (который, как я прочёл, написан с использованием самого себя) вижу пару мест где во время загрузки показываются знаменитые {{...}}
Это можно полечить с помощью docs.angularjs.org/api/ng/directive/ngCloak, но ИМХО это не критичный «недочет», если использовать систему в качестве админки, пользователи все равно ничего не увидят.
yurash, спасибо за обратную связь!
Основной план по монетизации пока хостинг и on-premise DevOps решения. Мы используем CoreOS + Docker инфраструктуру для изолированного запуска приложений. Именно она используется для запуска демонстраций.
По roadmap основные направления выглядят на данный момент так:
— Интеграции и двусторонний обмен данными с наиболее популярными сервисами (Почта, файловые хранилища, социальные сети, SIP, SMS, Платежные системы и т.д.)
— Поддержка наиболее популярных SQL БД (MySQL, MSSQL, Oracle, и т.д.). Сейчас есть Postgres.
— Поддержка различных библиотек представления и выделение angular представления в отдельный модуль. Пока кандидаты на реализацию: React и ReactNative для мобильных устройств. Будем рады услышать здесь дополнительные предложения по реализации.
Насчет angular: спасибо за бдительность! Там действительно не хватало ng-cloak. Это хак, который прячет нутро angular. Исправили. Что касается сложности/простоты angular: у него есть свои плюсы и минусы. Мы его взяли за основу, т.к. он на данный момент самый популярный JS MVC framework. Но мы на него не завязаны и строим AllcountJS не зависимым от представления. Здесь примем любую помощь в создании AllcountJS frontend'а с помощью других framework'ов!
Основной план по монетизации пока хостинг и on-premise DevOps решения. Мы используем CoreOS + Docker инфраструктуру для изолированного запуска приложений. Именно она используется для запуска демонстраций.
По roadmap основные направления выглядят на данный момент так:
— Интеграции и двусторонний обмен данными с наиболее популярными сервисами (Почта, файловые хранилища, социальные сети, SIP, SMS, Платежные системы и т.д.)
— Поддержка наиболее популярных SQL БД (MySQL, MSSQL, Oracle, и т.д.). Сейчас есть Postgres.
— Поддержка различных библиотек представления и выделение angular представления в отдельный модуль. Пока кандидаты на реализацию: React и ReactNative для мобильных устройств. Будем рады услышать здесь дополнительные предложения по реализации.
Насчет angular: спасибо за бдительность! Там действительно не хватало ng-cloak. Это хак, который прячет нутро angular. Исправили. Что касается сложности/простоты angular: у него есть свои плюсы и минусы. Мы его взяли за основу, т.к. он на данный момент самый популярный JS MVC framework. Но мы на него не завязаны и строим AllcountJS не зависимым от представления. Здесь примем любую помощь в создании AllcountJS frontend'а с помощью других framework'ов!
Павел, а где непосредственно CoreOS запускаете? DO? Или что-то свое? Используете какое-нибудь сущетсвующее решение для «заказа» запуска нового докера?
DbLogs, сейчас используем DigitalOcean. Но мы не привязаны к хостингу и планируем разворачивать свою инфраструктуру там, где будет требоваться заказчику. В том числе и в частных облаках как on-premise решение.
Для запуска Docker контейнеров используем github.com/coreos/fleet.
Для запуска Docker контейнеров используем github.com/coreos/fleet.
Если не секрет, то как решаете вопрос с персистентностью контейнеров? Или пока с этим не заморачивались и нода «стирается», ну или контейнер привязыватеся к той или иной ноде?
DbLogs, не секрет. Никак не решаем. Контейнер уже содержит, все что необходимо для запуска приложения почти также как это сделано в Heroku.
В том то и дело, что хероку при перезапуске все что пользователь «наделал» стирается полностью. Там если нужна персистентность, то надо использовать внешние ресурсы. А мы в Orienteer, естественно, хотели бы, чтобы при остановке ноды данные пользователя не пропадали. В docker есть volume фишка, но когда у тебя облако, то возникает проблема переноса volume на другую ноду по необходимости. Обычно люди через ZFS решают, но хотелось бы что-нибудь из коробки…
Шикарно! Спасибо большое за статью!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AllcountJS: Делаем простую CRM с веб-интерфейсом и REST API за 15 минут