Dreammaker, ваш вариант красивый, но работать не будет, потому что в нем у вас предполагаются не переменные $a $b а константы.
вставьте этот кусок кода в .htaccess
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.mysite\.com
RewriteRule ^(.*)$ http://mysite.com/$1 [R=permanent,L]
PVasili, AndyM, похоже, OpenID - это именно то, что я хотел услышать в этой теме, спасибо, попробую разобраться.
Это предполагает наличие всех яиц в одной корзине.
А у меня ситуация когда портал сам по себе, а другие сайты - на других хостах, частично на других CMS, частично вообще самописные скрипты, к которым требуется прикрутить централизованную авторизацию.
SandyMan, спасибо, а первый алгоритм не встречался на php?
второй тоже обдумывал, но не представлял, как подступиться.
буду пробовать.
Вопрос не в том, какие там будут ключи и имена, а в том, как эти зоны будет индексировать гугл и яндекс :)
"Используя учетную запись Loginza" - а у меня должна использоваться учетная запись тематического портала.
Сам портал будет провайдером аутентификации.---------- Добавлено в 01:27 ---------- Предыдущее сообщение было в 01:20 ----------d1gi, если не связываться со всяким хитрым ajax, то самый простой способ - двойной редирект, на сервер аутентификации(где по кукам можно сразу идентифицировать) и обратно + запрос валидности.
Про "централизованно хранить куки" не понял, куки другого сайта не поставишь же.
От каждого ресурса будут свои стоять, если истекли - футболить на сервак за идентификацией.
А зачем ЧПУ? оставьте на файлах htm.
достаточно сделать начало и конец страницы двумя файлами, и включать их директивами SSI - даже PHP не нужно.
В файле у вас остается только контент, его правите прямо в каталожной структуре.
Любые изменения меню - в файлах футера и хедера соответственно.
Это самая быстрая связка, нагрузка минимальна.
Вот пример древнего сайта на SSI - причем это интернет-магазин:
http://650.ru
Если же нужно автоформирование меню - идеальный вариант SatXlite(без проблем), или ZebrumLITE(но она помудреней в плане кеша, заморочки с обновлениями контента)---------- Добавлено в 12:37 ---------- Предыдущее сообщение было в 12:23 ----------
СОГЛАШЕНИЕ: 5. Вы не имеете право распространять данный скрипт, а также модификации данного скипта на платной основе.
Ну и зачем вникать в такую систему?
По существу вы правы, но юридических перспектив, на мой взгляд, слишком мало - у нас два хозяйствующих субъекта и договор клиента с одним из них. Как я уже писал выше, регистратор вполне может выполнять свою часть договора с вами - направлять заявки на регистрацию. Если они не обработаны третьей стороной - это не вина регистратора. Точно так же с продлением, это просто передача заявки - обработали - ну и славно. Нет - значит нет.
Вообще это классическая схема ухода от ответственности держателя активов - отсутствие прямого договора с потребителем.
При таких схемах в любом бизнесе мало что светит через судебное разбирательство, если договора без ошибок написаны.
Вспомните все суды по доменам - там спор идет на основе других законов РФ, например о товарном знаке, но никак не на основании правил регистрации доменов. Поправьте, если я не прав и были прецеденты.
живой пример такого обтекания: http://haiku3.ru
