Станислав Макаров

Для этого придумали динамический import. Либо пользуйтесь им нативно (если ваша среда исполнения это позволяет), либо пропускайте это через бандлер. Пример для вебпака.

существует ли способ идентификации пользователя на WEB-ресурсе по текущему логину Windows?

Существует. Протокол называется Kerberos в сочетании с SPNEGO. Существует RFC по его использованию вместе с HTTP, http-схема аутентификации называется Negotiate. Читайте подробно тут: RFC4559. Если очень коротко, то веб-сервер должен прислать заголовок www-authenticate со значением negotiate если готов поддерживать такую схему аутентификации. Браузер, в свою очередь, отвечает токеном.

В большинстве браузеров можно настроить поддержку этой схемы аутентификации. Со стороны сервера тоже разумеется нужна поддержка. Возможно вы захотите прибегнуть к помощи упомянутых Иван Шумов identity-серверов. Например Keycloak точно поддерживает Kerberos. На нём же можно и LDAP подцепить в качестве базы данных пользователей. Обычно так поступают, т.к. протоколы federated identity вроде OpenID Connect обычно гораздо проще реализовать со стороны веб-приложения, нежели все тонкости аутентификации вроде вашего случая или, например, двухфакторной авторизации через Google Authenticator.

Надеюсь это отвечает на ваш ИЗНАЧАЛЬНЫЙ вопрос о ТЕКУЩЕМ логине в домене. Т.к. сам по себе LDAP подключенный к сервису это хорошо конечно, но это всё-таки не SSO.

Вот доки по настройке этого в Keycloak: https://github.com/keycloak/keycloak-documentation...

В вебе традиционно забивается на синхронизацию данных - так я думаю.

Здравствуйте:

• https://en.wikipedia.org/wiki/Optimistic_concurren...
  
• https://developer.mozilla.org/en-US/docs/Web/HTTP/...
  
• fideloper.com/etags-and-optimistic-concurrency-control
  

Так что да - проблема глубокая, глобальная, встречается в большинстве многопользовательских информационных систем и уже довольно неплохо проработана на разных уровнях - от различного уровня изоляции транзакций в БД, до высокоуровневых механизмов в том же HTTP (см. ссылке выше). То что вы так думаете - это вы просто ещё не сталкивались, т.к да, многие в своих относительно примитивных веб-задачах забивают на проработку этих вопросов.

А если вам гугл-докс, так это уже куда более сложные материи, см. Operational transformation и CRDT.

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

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

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

Будем говорить о веб-клиентах и нативных клиентах (либо ненативных, но на не-веб платформе, например на дотнете или джаве).

Основная причина, по которой веб-клиенты всем нравятся - это идеальное решение вопроса деплоя приложения. Хорошо, не идеальное, но самое удобное для пользователя.
Чтобы какой-то код работал, его нужно либо доставить конечному потребителю, либо запустить у себя и доставить результат.
Сначала запускали у себя и доставляли результат в виде полностью готовой HTML-странички с минимумом скриптов или вообще без них. Это было время генерации страниц на сервере.
Клиент всегда хотел быстрого отклика и различных красивых анимашек, в общем хорошего user experience. Когда user experience и быстрый отклик был важнее, писали нативный клиент (и до сих пишут, когда это важнее).
Потом как-то собрались хорошие инженеры и запилили v8. Оказалось, что можно даже JS выполнять быстро. Планка скорости поднялась, остальные (SpiderMonkey и т.д.) начали подтягиваться.
Отклик уменьшился, больше кода стало возможным разместить на клиенте. Анимация 20 снежинок на странице больше не грузила процессор клиента на 100%.
Вопрос лёгкости деплоя кода начала перевешивать вопрос тормозного JS. Выяснилось, что facebook лучше смотреть на веб-страничке, чем скачивать отдельное приложение. А, ну и да - веб-песочница кроссплатформенна. Да, есть несовместимости между браузерами (особенно раньше), но жить гораздо приятнее, чем писать версии приложения под каждую ОС и собирать их. Программисты дешевле в разы.
Мобильные платформы тормозят сильнее. Под них продолжают писать нативные приложения.

Итог: всегда приходится решать, стоит ли приложение того, чтобы клиент заморачивался с его установкой и следил за ним. Это дело продакт-менеджера. Нет ничего проще установки и обновления веб-приложения - нужно нажать F5. Но тем не менее я всё еще хочу видеть свою IDE в качестве десктопного приложения. Ну и большинство решений на том же Электроне - это жесть. Возможно, через 10 лет всё будет совсем по-другому.

P.S. Насчёт взлома приложений не согласен - ключевую логику можно держать и на сервере, но это можно делать и в случае веб-клиента, и в случае десктопного.

Какая в меня ошибка ?

Ваша ошибка: Fatal error: Call to undefined function pg_connect() in /var/www/mysite/lab2/stocks.php on line 17

Как ее исправить ???

Если уж вы используете расширение для работы с постгрес, его необходимо загрузить. Конкретный рецепт зависит от вашей операционки: stackoverflow.com/questions/7438059/fatal-error-ca...

Суть любого робота в автоматизации того, что делать руками не хочется или невыгодно. А что конкретно автоматизировать, это зависит от конкретного случая.

Примеры:

• боты для DDOS - см. определение DDOS-атаки
  
• боты для сайтов/форумов/чатов - рекламный спам, авторегистрация пользователей; бывают и полезные вещи, например боты-нотификаторы. В ICQ был в своё время популярен бот, отвечающий на ряд запросов - можно было спросить прогноз погоды или рассказать анекдот;
  
• боты в MMO-играх: сбор ресурсов, ожидание в очередях и т.п. Также спам в чаты (продажа ресурсов/золота, как легальная так и не очень, рекрутинг в гильдии);
  

Откройте для себя NuGet, NPM и Bower.