Ахахах, это в ангуляре логика в шаблонах? Вы, походу, реакт не видели) Там шаблоны в логике - еще лучше. И причем без всяких разделителей хуякс html посреди="js кода".
Ну и вообще - не надо писать логику в шаблонах, в шаблонах должна быть лишь отсылка к логике в js.
Да, о том и речь – автор делает на своем поддомене всё что хочет, но при этом с главного домена чтобы куки не ушли. Но вы упомянули отличный пример фишинговой уязвимости, как с ней бороться? Надо сделать какую-то единую систему аутентификации, которая незаметно для пользователя с помощью токенов обменивается новым комплектом кук для аутентификации на новом домене.
Сейчас как раз используется система на основе white-listing, но цель — от нее избавиться, дать неограниченный доступ без взаимной кражи кук. Грубо говоря — мультиблоггинговый сервис с полной кастомизацией.
Да, это вариант. Но вы представьте как сделать доступ по сертификату широкой публике посетителей. Например посещаемость хотя бы 10000 уников в сутки, каждому сертификат? Мне интересно именно как это сделано безопасно в сервисах типа tumblr.
Задача была поставлена иначе – не очищать код, а дать полный неограниченный доступ к HTML. Но при этом ограничить авторов от вмешательства друг к другу, воровства общих кук.
А что значит «Базовый фрейм перекинуть на страницу для фикса сафари, потом перекидывать на страницу приложения обратно.» Редирект туда-обратно между сайтами?
Держите в курсе, если будут еще решения. Идиотизм какой-то, лишают вебмастеров возможности устанавливать крутые виджеты.
Купил minidisplayport->vga оригинальный, полгода никаких проблем, работаю на 2 экрана. Стоимость штуки — 2 килорубля. Можно заказать подешевле неоригинал.
Вы предложили неграмотное решение. Опытные администраторы не используют phpmyadmin и прочие визуальные обёртки над отличными консольными приложениями, тем более на продакшене. Во-первых, есть удаленные средства — MySQLWorkbench, если нужны рюшечки, а во-вторых, консоль в умелых руках значительно удобнее.
Второй повод — человек не спрашивал как ему перенести с выгрузкой, ему нужно перенести копированием директории, т.к. у него сдох сервер и он уже не может на нём запустить выгрузку.
Просто надо понимать когда стоит делать rich client application с клиентсайд логикой, а когда достаточно использовать обычную серверсайд логику с рюшками на jquery. Тем более, что эта серверсайд логика уже готова, на мой взгляд, не очень правильно перетаскивать её на клиента, если это не было задумано изначально.
+1, Panya
А так, ссылка на стэк хорошо отвечает на этот вопрос. Сам из этих трёх выбрал bb, так как SC ужасно документирован (70% документации DEPRECATED, гайды неполны, что-то нагуглить невозможно) и сейчас вся эта суматоха с amber/ember, а у knockout смешан html и js, что я не одобряю, хотя ko значительно короче в написании несложных интерфейсов. bb при этом требует достаточно объемного кода на первом этапе, но это позволяет уменьшить его объем на последующих. Быстр, мал и не смешивает логику с вёрсткой.
А почему лучше ставить SSD на место HDD? Ведь в таком случае не будет работать хитрая система убирания головок при срабатывании акселерометра. И еще такой вопрос – каким образом можно раскидать текущую систему на эти винты? Как вариант есть TimeMachine, но учитывая малый размер SSD придется заранее перенести лишнее на отдельный винт.
Ну и вообще - не надо писать логику в шаблонах, в шаблонах должна быть лишь отсылка к логике в js.