Общее хранилище js скриптов и выдача их через php

f0rym4anin

Новичок
Общее хранилище js скриптов и выдача их через php

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

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

В последнее время при создании сайтов приходится все чаще использовать разные яваскрипты
В той или иной степени используются:
- Jquery и платины к нему
- Prototype
- Ckeditor
- Lightbox
- всяческие скрипты графикопостроители
- самописные скрипты
- т.д. и т.п.


Таким образом, стала проблема отслеживания скриптов и их версий для всех сайтов

Самым простым вариантом мне видится прописания rewrite_rule для директорий /js/ всех сайтов и перенаправление запросов к этим директориям на общий скрипт

Содержащий что-то в духе
PHP:
$path = $_GET [‘path’];
if (file_exists(CORE_DIR.$path)) {
    $content = file_get_contents (CORE_DIR.$path);
    header('Content-Type: text/html; charset=utf-8');	
    echo $content;		
}
else {
           
	header("HTTP/1.0 404 Not Found");
}
Это просто пример для понимания того, что я планирую сделать

Возникает вопрос, что и как тут фильтровать, чтоб обезопасить себя от неприятностей
На данный момент количество файлов в общем хранилище js около 1200
Заводить реестр файлов и обновлять его не хотелось бы

Как минимум нужно отфильтровать .. (как лучше это сделать? Str_replace?)
Проверить, при помощи dirname, чтоб подключаемый файл точно находился в директории /js/ движка

Какие еще действия порекомендуете предпринять?
Может использовать что-то другое вместо file_get_contents?

Заранее спасибо!!!
 

The employer

Новичок
Если будет работать file_get_contents, то будет работать и простой симлинк.

То есть нужно держать один каталог со стандартными библиотеками, а на каждом сайте сделать просто симлинк на этот каталог.

-~{}~ 24.05.10 15:30:

Нужно будет только веб-серверу разрешить ходить по симлинкам.

Для апача прописать в htaccess: +FolllowSymLinks
 

f0rym4anin

Новичок
Я так понимаю, данный вариант вынудит мена прописывать в каждом .htaccess путь к хранилищу .js

Т.е. если у меня, что-то поменяется с путями, то нужно будет на всех сайтах все перепрописывать


Стараюсь максимально уйти от этого и иметь возможность все редактировать в едином месте.
 

The employer

Новичок
Смотря что поменяется. Если поменяются имена или пути файлов (например, было /js/jquery/jquery-1.4.1.js а стало /js/libs/jquery/jquery-1.4.2.min.js - то все равно надо будет поменять ссылку во всех шаблонах всех сайтов.

Самое интересное, что в структуре каталогов этих сайтов ничего менять не надо будет. Как был симлинк /www/site1/js -> /www/common/js - так и остался.

А если обновилось содержимое файла, а путь как был /js/jquery.js так и остался таким же - то ни на одном сайте ничего менять не потребуется.

Кстати, есть еще один неплохой способ (мы пользуемся именно этим способом). Подойдет ли он Вам - смотрите сами.

Код каждой общей библиотеки лежит в отдельном репозитории. И код каждого проекта (сайта в Вашем случае) - тоже лежит в отдельном репозитории.

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

При обновлении библиотеки (выход новой версии, багфикс) - новый код библиотеки заливается в репозиторий библиотеки. А рабочим копиям проектов просто делается update.

У нас так живет несколько десятков проектов, причем структура двухуровневая - все проекты основаны на репозитории платформы, а к репозиторию платформы подключены репозитории библиотек - smarty, simpletest, phpdocumentor, jquery и т.д.

Работает замечательно.
 

f0rym4anin

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

Я тоже держу на каждом сайте папки /js/ и /admin/js/

mode_rewrite прописан так, что если запрошенный файл имеется в указанных дирректория то сервер выдает его, если файла нет, то /index.php получит необходимые параметры и выдаст нужный файл из ядра.

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

The employer

Новичок
Странная схема, но Вам виднее, конечно.

Фильтровать достаточно путь к файлу, указанный в URL. Можно регэкспом по маске просто.

И еще проверять имя файла на валидность (чтобы соответствовало общим требованиям для имени - не содержало недопустимых символов).

Одним регэкспом делается и то, и другое.
 

f0rym4anin

Новичок
Автор оригинала: The employer
Странная схема, но Вам виднее, конечно.
:)
Схема такова
Все общие .js хранятся в ядре и никогда не хранятся в папке /js/ какого-либо из сайтов
допустим:
/js/jquery/jquery.js
/js/core-catalog.js
Відаются из ядра

А вот специфические для определенного сайта .js допустим
/js/site-catalog.js
Реально лежат в папке /js/ сайта.

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

По поводу регэкспа понятно

Хочется еще узнать насколько кошерным является выдача скриптов картинок и прочего через file_get_contents :)
 

The employer

Новичок
Надо хорошо понимать, зачем Вы это делаете. Такая схема нагружает сервер.

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

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

При обновлении картинки в базе - на всех серверах эта картинка стиралась, а линк для выдачи в браузер - менялся, чтобы гарантированно сбросить клиентские кэши.

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

Нам это надо было для решения конкретных задач: быстро и с минимальной трудоемкостью вводить сервера в кластер, и убрать постоянный rsync между машинами (NAS отсутствовал)

Подумайте, надо ли это Вам.
 

f0rym4anin

Новичок
По большому счету у меня нет крупных сайтов
Все это мелкие интернет-магазины, сайты юридических компаний, художников, скульпторов и прочее.
Наиболее посещаемый ресурс имеет 500 хостов в сутки:)

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

А вот бекєнд в купе с постоянным желанием владельцев сайтов что-то усовершенствовать ставит перед необходимостью что-то постоянно менять в куче абсолютно разных сайтов.

По этой причине было принято решение собрать все воедино
Как php так и js.

Цель была такая. Вопрос нагрузки, вроде как сейчас неактуален.
 

The employer

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

То есть один экземпляр серверного кода обслуживает множество сайтов, поднимая дизайн, настройки доступа к базе и все прочее - по имени домена.

В этом случае задача решается автоматически, да еще и на хостинге можно сэкономить :)
 

f0rym4anin

Новичок
А что есть портальная структура? Где почитать?
У меня примерно так и есть, только все равно полной унификации модулей добиться не получится :(
 

The employer

Новичок
Да там особо нечего читать. Очень простая штука, все что нужно я уже написал в предыдущем сообщении.

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