Павел Волынцев

В правилах веб-сервера перенаправляйте запросы к статике (CSS и картинки) в PHP. Просто отдавайте 404 Page Not Found.
К примеру, для веб-сервера nginx, условно:

# Не перенаправлять запросы про несуществующие статические файлы в PHP
location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|woff|ttf|eot|svg)$ {
    root /var/www/applicaion; # путь к приложению
    access_log off; # логи не писать
    try_files $uri =404; # не вызывать PHP
}

1. Сокеты для постоянного обмена, если нужно оперативно данные с сервера получать. Можно и оправлять.
AJAX если данные запрашиваются по мере необходимости.
2. Используй SSL и не беспокойся за сеансовый ключ

.hea {
   position: absolute;
   width: 100%;
   left: 0px;
}

codepen.io/copist/pen/wKzGeq

https://gmail.com/ работает по большей части без перезагрузки страниц
наше вот https://icons8.com/web-app тоже на Angular.JS

Пользуйтесь ключами RSA, у каждого пользователя своя пара ключей. Один (публичный) передаётся на сервер, другой (приватный) остаётся у пользователя. Когда делается транзакция, например покупка, то на сервер должна поступать информация:

1. идентификатор покупателя
   
2. номер счёта покупателя
   
3. идентификатор продавца
   
4. номер счёта продавца
   
5. идентификатор покупки
   
6. валюта
   
7. точная сумма покупки
   
8. точное время транзации в таймзоне UTC
   

К каждой транзакции должен прилагаться отпечаток от всех этих значений, подписанный с использованием приватного ключа покупателя. На сервере этот отпечаток должен проверяться с использованием публичного ключа того же пользователя. Публичный ключ можно хранить в базе же. Он только для сверки.

Чтобы выполнить транзакцию (покупку), нужно проверить, хватает ли средств на балансе пользователя-покупателя. Для этого нужно изъять из базы все транзакции пользователя-покупателя, по каждой транзакции провести проверку отпечатка и суммировать те, у которых отпечаток корректный.

Проверяйте время транзакций. У каждого покупателя все транзакции должны быть строго хронологическими. Не должно быть чтобы покупка N+1 была ДО покупки N.

Это вычисляется долго. Чтобы ускорить вычисление остатка, можно ввести специальный тип транзакции "состояние на начало месяца". Его должны выполнять сторонний доверенный сервер, имеющий свою специальную пару ключей. Тогда текущий баланс = последний остаток на начало месяца + все поступления - все оплаты. Вычисляется значительно быстрее.

Если злоумышленник взломает базу данных, то внесёние записей будет чрезывычайно затруднительным, потому что подделать отпечаток транзакции будет невозможно. Слабое звено - можно просто выгрузить базу или таблицу в файл и затем дропнуть таблицу или базу и шантажировать вас потерянными данными. Чтобы исключить такое, запретите пользователям (не покупателям, а тем, которые подключаются к базе) делать DROP TABLE/DATABASE. Ещё делайте резервные копии. Ещё держите зеркало базы данных.

Всё что я описал, будет бесполезно, если злоумышленник заменит исходный код платёжного сервера, так как он сможет просто вырубить все проверки на отпечатки. Поэтому платёжный сервер не должен быть скриптовым. То есть не PHP, node, Python, Ruby. Это должен быть компилируемый код. С цифровой подписью. Сервер не должен исполнять приложения с отсутствующей или неправильной цифровой подписью.

Но это не мешает подменить список доверенных центров сертификации на сервере, чтобы запустить поддельное приложение вместо платёжного сервера. Поэтому на стороне СУБД нужно реализовать механизм, который не даёт подключиться к базе любому приложению. Это приложение должно иметь специальный механизм доступа. Ограничение по IP, специальные заголовки, особенная сессия. Значит это не MySQL и, скорее всего, не PostgreSQL.

Ещё о каком-нибудь головняке рассказать или уже достаточно?

Специалисты из WebMoney, PayPal, Yandex.Деньги и онлайн-банков сейчас не скрывая улыбки смотрят на мой алгоритм. Привет вам всем, друзья!

Относительно реализации на PHP. Два сервера с запросами через AJAX не сделают сервер надёжнее, потому что всё можно подделать в браузере.

Нужно предотвратить доступ пользователя к серверу. В Интернет огромное количество статей на эту тему. Я боюсь, что полный список средств предотвращения доступа я просто не вспомню. В любом случае, способов взлома больше, чем методов защиты в PHP.

Вот списочек способов проникнуть на сервер:

• Через уязвимости серверных компонентов;
  
• Через уязвимости в веб-окружении сервера;
  
• Через удаленное выполнение произвольного кода;
  
• Через наличие переполнений;
  
• Через инъекции (внедрение кода) (например, SQL Injection);
  
• Через обход системы аутентификации веб-ресурса;
  
• Через XSS / CSRF;
  
• Через перехват привилегированных аккаунтов (или сессии таких аккаунтов);
  
• Через Remote File Inclusion / Local File Inclusion;
  
• Через компоненты CMS, CMF и фреймворков с известными уязвимостями;
  
• Через перенаправление на другие сайты c помощью открытых редиректов;
  
• Через сканирование директорий и файлов (поиск дампов, данных про git, svn);
  
• Через подбор паролей.
  

И вот списочек способов снижения вероятности проникновения и нанесения непоправимого ущерба:

Состояние серверов

• Держи сервера в актуальном состоянии, следи за найденными уязвимостями, обновляй серверные приложения
  
• Делай бакапы файлов и баз данных, держи зеркальную базу данных; в случае беды - используй копию
  
• Используй виртуальные машины, делай периодически снимки, а в случае взлома восстанавливай машины из снимков
  
• Больше не вспомню. Держи админа под рукой.
  

Доступ к серверам

• Не подключайся от имени пользователя root, заведи другого.
  
• Установи на всех пользователей длинный пароль.
  
• Запрети всем пользователям делать sudo. Можно разрешить делать некоторые отдельные операции, например, nginx reload.
  
• Для подключения к серверам пользуйтя SSH или SFTP, авторизация по ключам
  
• Смени порты сервисов SSH и SFTP
  
• Установи ограничение на список IP, с которых можно подключиться к серверу. Сделай себе белый IP адрес.
  

Внутренние сервисы

• Если всё приложение на одном сервисе, то все внутренние службы (mysql, memcached, raddis, rabbit) должны слушать только интерфейс 127.0.0.1. ( habrahabr.ru/post/212265 )
  
• Если приложение включает несколько серверов (отдельно база, отдельно PHP), то есть представляет собой кластер, то службы должны слушать только те IP, которые относятся к кластеру.
  
• Смени стандартные порты всех сервисов
  
• Пользователю UNIX от которого работает PHP-FPM / NGINX/ APACHE, должны быть открыты для записи только несколько директорий (upload, логи, временные файлы), а для исполнения - вообще ничего нельзя.
  
• Пользователю базы данных не должны быть доступны деструктивные и небезопасные операции (DROP/ALTER/CREATE PROCEDURE), может быть даже для INSERT/UPDATE/DELETE в данных по финансам использовать другой аккант в базе данных
  

Приложение PHP

• Защищай сайт с помощью SSL
  
• Используй дополнительный платёжный пароль, ограничивай количество попыток оплаты с неверным паролем
  
• Используй server side http cookie, короткие сессии с привязкой ключа сесии к IP и UserAgent клиента
  
• Все запросы к базу должны быть только с использованием связываемых параметров, никаких конкатенаций запроса с параметрами (Внедрение SQL-кода, SQL injection, php.net/manual/ru/security.database.sql-injection.php и другое по фразе SQL injection )
  
• Не доверяй проверкам данных на стороне клиента. Да, они ускоряют работу, но их можно легко подделать. Поэтому все проверки дублируй в коде на сервере.
  
• Не доверяй данным пользователя: фильтруй строки, отрезай теги, укорачивай до допустимой длины, приводи к числам все числа (wikipedia: CSS, Cross Site Scripting — «межсайтовы..., XSS для новичков, Яндекс: XSS-атаки и другое по фразе "XSS")
  
• Все запросы на сервер должны сопровождаться токеном безопасности ( https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D... https://learn.javascript.ru/csrf habrahabr.ru/post/235247 и другое по фразе "CSRF" )
  
• Нигде не делай авто-редирект на страницу, указанную в параметрах запроса - так обычно делают, чтобы после логина вернуться туда, откуда была вызвана форма логина
  
• Про содержимое транзакций уже писал, не знаю что из этого тебе пригодится
  

phpStorm - слишком монструозный и навязчивый, как будто для проектирования самолета;

Не стесняйся признаться, что ты всегда мечтал сконструировать ракету. Слезть с phpStorm будет сложно, особенно после взлёта твоей ракеты.

Читай про FileSystem API и DirectoryReader
habrahabr.ru/post/112286
https://developer.mozilla.org/ru/docs/Web/API/Dire...

Как вариант ещё поднять микро-приложение на node.js, буквально 20 строк и читать файлы через AJAX
Любым пользователям можно доступно рассказать, почему нужен это микро-сервис.

Общий принцип: нужна таблица в базе данных, страница с формой для подписка, логика для сохранения имейла в ту таблицу, интерфейс для просмотра списка подписчиков.
Дополнительные плюшки: редактор писем и массовые рассылки либо интеграция с внешними системами для рассылки писем.

Как вариант - установи чужой плагин, посмотри как он работает и изучи его исходный код.
Самый простой - https://wordpress.org/plugins/email-subscription/

Шаблоны проектирования и шаблоны программирования - это описания лучших вариантов решений для типовых задач. Многие тыщи программистов уже решали такие типовые задачи и у большинства получалось добиться хорошего результата приблизительно одинаковым способом.

Под задачей иногда подразумевается глобальные:
как сделать так, чтобы второй программист понял мой код (например, MVC/MVVM - разделение кода на логику и представление, шаблонизация Twig/Jade, фреймворки)
как сделать так, чтобы мы кодили быстро (фреймворки, деление кода на фронт/бак, шаблонизация Twig/Jade, доступ к данным через ORM/ADO, препроцессоры LESS/SCSS/Stylus)
как сделать так, чтобы мы к себе смогли легко включить сторонний модуль или наш код могли подключить к чему-нибудь (плагины, модули)

Средне-масштабные
как сделать так, чтобы по возможности было меньше обращений на сервер (кэш, lazy init, client-side validation, rich internet application)
как обрабатывать долгие запросы (очередь, асинхронная обработка, comet, websocket, long polling)
что делать, если интерфейс "замёрз" (показать spinner, вывести "сожалелку :(")
как сделать мега-форму из 50 полей (сделать пошагового мастера)
как показать что-то очень важное (popup, модальное окно)

Мелкие
как сделать так, чтобы интерфейс реагировал на поведение пользователя (события)
как сделать так, чтобы код выполнялся периодически (таймеры, интервалы)
как сделать так, чтобы у меня скрипты JS подключались по мере необходимости и только один раз (requirejs)
как сделать так, чтобы у меня одинаковая задача запускалась только если предыдущая уже закончилась (например, не посылать запрос AJAX, если предыдущий не отработал; не анимировать два раза один и тот же объект DOM)

Вообще невозможно сказать, что каждая из них решается комбинацией синглотонов. Или фабрик. Там куча-мала, просто завал мелких фрагментиков кода, блоков логики, в каждом из которых что-то было сделано по шаблону.

Вот тут на примерах на Javascript с объяснением habrahabr.ru/post/132472

У меня на этих курсорах двусторонние стрелки.


Первый раз вижу курсоры односторонние. Всегда же были туда-сюда. А что такими делать?

Хочу тоже самое но в вебе, для возможности быстрого поиска кодовых полезняшек всей командой и только командой, т.е. доступ только авторизованным.

Stackoverflow + google ? Много, обо всём, актуальное. Можно искать.

$.each(flipnabory, function(index, flip){
    $(flip).turn({
        width: 220,
        height: 250,
        autoCenter: true,
        display: 'single'
    });
});

Вместо имени переменной flipnabory лучше flipset или flips, чтобы не смешивать английский и русский.

https://icons8.com/web-app/ 15 000+ иконок flat style и утилиты для работы с иконками

Где брать элементы дизайна для веб?

Тег <i /> - это самый короткий тег среди всех, что есть.
Кроме прямого назначения "italic" он также ассоциируется с "icon".
А классы на него можно навешать какие угодно, так же как и на <span> <strong> <div>

А ты все слова пытаешься перевести?

abstract class A extend B interface C
{
  private property $b;
  final protected function x() { return new static; }
}

абстрактный класс А, сын Бэ и лицом-похож-на Цэ
{
   частная собственность $бэ;
   конченная защищаемая функция икс() { вернуть новую неподвижность }
}

Моё частное мнение - достаточно знать, как работает языковая конструкция и в идеале знать, как правильно произносится на английском. Мне лично моё произношение и исковерканные "привАт" "пэхапэ" "пропертЯ" "абстрАкт", "на сях", "си шарп", "" - были до лампочки, пока не пришлось объяснять свой код в команде из англоговорящих программистов и задавать им вопросы по их коду. А ещё я общался с тайцами и индусами и теперь тщательно произношу именно английские версии всех названий технологий, зарезервированных слов и торговых марок. Зиракс, МАйкроСофт, ЭйчТиЭмЭль, ПиЭйчПи, прАйвит, Эбстракт :)