SPA application, авторизация и что рендерить backend'y?

Question

[AoA]

Добрый день, интересуют лучшие практики по организации SPA приложения с REST API, что стоит , если вообще стоит, рендерить на стороне backend ?

Какие вижу варианты:
1. рендерим index.html, далее все view рендерим клиентом
2. рендерим сервером login page, авторизовываемся, рендерим сервером index page, далее уже клиентом
3. ничего не рендерим сервером, c REST авторизовываемся token'ом

какой подход считаете наилучшим, что применяете сами, как организовываете authentication and authorization ? Cпасибо!

Answer 1

[Сергей Протько]

что стоит , если вообще стоит, рендерить на стороне backend ?

Ничего вообще не надо редндрить. Сервер отдельно, клиент отдельно. Они никак не должны пересекаться. server-side рендеринг применяют как один из вариантов оптимизаций + для поисковиков. Это нужно далеко не всем и далеко не всегда.

c REST авторизовываемся token'ом

Еще следует помнить, что хранить секьюрные данные доступными из JS не шибко удобно (браузеры увы не предоставляют секьюрного хранилища пока-что), потому лучше токен сэтить сервером в httponly куку. Тогда браузер будет все сам разруливать и будет чуть чуть более безопасно. К сожалению другого способа в контексте SPA как организовать это дело секьюрно я не знаю. В общем случае и в localStorage хранить норм, но меня это смущает. Ну и естественно все под HTTPS, иначе все загоны по безопасности идут прахом.

Comments

[raiboon]

"Ничего вообще не надо редндрить" угу, конечно. Уже же все поисковики идеально сами обрабатывают js :/

[Сергей Протько]

raiboon: дочитайте абзац. Не для всех SPA вообще это нужно. А даже если и нужно, Angular не поддерживает server-side рэндринг, а стало быть, нужно для поисковиков подключать page fragments api + через какой phantomjs генерить эти фрагменты. Да и готовые решения есть.

[Yuri Shikanov]

raiboon: просто оставлю это здесь https://medium.com/ben-and-dion/is-it-time-to-go-s...

Answer 2

[Александр Кондауров]

Работаем по третьему варианту. Очень удобно. Разрабатываем проекты внутри своего отдела, работаем в двоем. Я делаю restful backend. В это время коллега ставит фейковые данные и делает приложение на ангуляре. Потом когда backend готов, убираем заглушки и радуемся xD Люди, которые ставят прототип разрабатываемого проекта, не видят полной картины, и мы часто делали ошибки когда backend & frontend были сплетены и делали все по их прототипу. Сейчас можно сказать делаем по "максимуму" так как тщательно продумываю backend, нужные контролеры, модели. PS Переписали пару проектов которые были на php (фреймворк Yii): Интерфейс стал интуитивно понятным, множество контроллеров сократилось до 2 - 3х с понятными экшинами. Нету дометивации расширять проект, так как код и архитектура прозрачна

Answer 3

[Milyh]

Александр Кондауров Сергей Протько мне вот интересно, если вы идёте по пути 3 решения как вы делаете (если она у вас есть) авторизацию. Я имею в виду Oauth. Вот есть у вас кнопка - войти через ВК. В ссылке для этой кнопки желательно (я бы сказал - обязательно) нужно прописывать STATE - случайно сгенерированную строку для защиты от атак. Этот STATE потом проверяется на сервере. Но как его проверять, если он был сгенерирован на клиенте?

Comments

[Александр Кондауров]

Если честно я не могу понять вопроса, мб спать пора..
Авторизация у нас конечно есть, как же без нее, логины и пароли хранятся в нашей бд
Авторизацию через соц сети мы ни разу не делали пока, почти все инструменты пишутся под клиентов.
Есть страница входа, логин и пароль которой улетает на проверку (типа /api/login) и если ок то приходит токен, его сохраняем в local storage и все.
В ангуляре написаны интерсепторы на заголовки ответов с помощью которых ангуляр рендерит страницу входа, или 404 ошибку, или 500

[Milyh]

Так вот в том то и дело, что у вас нету авторизации через соц сети.

Answer 4

[Валентин Дубровский]

мы в проектах юзали второй вариант. Минусы примерно такие:
1. Нету возможности полноценно разделить frontend и backend части. Часто приходится лазить в к бекенду, чтобы что-то добавлять/изменять и т.п.
2. Думал будет несколько минусов, но что-то видимо нет.

Если полностью разделить бекенд и фронтенд, это конечно классно, но нужно учитывать некоторые факторы:
1. Лишние запросы.
2. Любой желающий может чекнуть код, который реализовывает функционал для авторизированных юзеров.
но зато фронт живет отдельно от бекенда, и это очень-очень круто, особенно если у вас большой проект, имхо конечно же,

Comments

[Alexander Tartmin]

Не согласен на счёт любого желающего если код обфусцировать ;)
А вообще, ангуларом вроде как можно только данные гонять туда-сюда, так что не обязательно важную бизнес-логику держать на фронте.

[Валентин Дубровский]

Alexander Tartmin: если посидеть и попыхтеть, то я можно понять логику ну имхо конечно же. не я не спорю, это конечно повышает защиту кода, но код то остается в public.

[Alexander Tartmin]

Валентин Дубровский: защиту от школьников сделать не так и сложно, а от хорошего специалиста или кто действительно собирается разобраться что и как у вас там работает - нельзя. Я думаю что если кто-то захотит узнать как всё устроено, то ему даже рендер на бэке не помеха будет ;)