Сессия работает ТОЛЬКО на одном домене!
Чтобы заставить под той же сессией (авторизацией то есть) нужно плясать с бубном... кукисы то есть заюзать.
ИМХО не так прямо и просто это делается... б.м лучше поглядеть в сторону OpenID?

BesTime, используй свои кукисы и базу данных для хранения сессий.
Кукисы ставь с 5-ю параметрами, где 5-й - домен, его вводи так:
'.example.com' - обрати внимание на точки перед названием домена. Т.е. кукисы будут доступны на всех поддоменах.

neadekvat так кукисы вроде не безопасно использовать и вроде можно подменить?

Кикисы нужно сделать с сохраненным с них СЕССИОННЫМ ключом! при закрытии брозверя оный, как и сессия, уничтожается (теряет актуальность) - потому и гимор есть здесь... не делается всё на автомате как заведение сессии да один (основной) домен... Программировать нужно вручную процедуры проверки легальности входа юзверя на субдомен.

я имею ввиду мне нужны сесии используемые на домене example.com для поддомена one.example.com которые находятся на одном и томже сервере,папки лежат на одном уровне

Неважно на одном или не одном сервере! и папки тут ри при чём! Встроенный механизм сессий не позволяет (для целей секурности) эксплицировать сессию вне одного домена!

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

При авторизации юзверя сессионный ключ записывается в сессию на основном домене, в заводимый кукис, который должен быть доступен и на субдомене, и в БД как тут подсказали. Но возможно и без юзанья БД, но гимора не меньше... так на так...
При переходе юзверя на субдомен оный ДОЛЖЕН снабжаться в ссылке текущим сессионным ID (не ключом!-последний СЕКРЕТЕН!) и по нему на субдомене должен проверяться легальность входа юзверя. т.е что ТАМ сессия еще существует!
Это общая схема. Детали это уже дизайн и девелопинг

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

И немаловажно: чтобы юзверь разлогиниваясь стирал процедурой логаута тот кукис!

В БД может остаться СТАРЫЙ сесс-ключ! и хана!
Ваще БД не панацея... сессии это надежно...

а зачем старый ключ чтобы стирался? он просто будет заменяться если пользователь еще раз авторизуется

ключ не стирается а заново генерится. стирается кукис чтобы не светиться в брозвере когда юзверь скажем работает из кафе (не своего ПК). Так принято по секурности... но дело хозяйское... нынче чего только народ не "творит"!

об этом я даже не подумал спасибо то что предупредил, это серьезная дыра в безопасности сайта

вот-вот!

Представим на секундочку, что сессия нужна для хранения лишь бесполезной информации так, чтобы каждый раз за ней не бегать. Если мы работаем с денежной системой, допустим, то нам в любом случае необходимо будет каждый раз дёргаться и получать эти данные с БД, а не в сессии хранить. Итого сессия становится бесполезной.
Разработчики тоже не дураки, если поддомен разграничили с сессией, то явно подразумевается, что поддомены существуют для работы с иными сервисами, а не для одного приложения.
Мелочи можно вообще в куки кидать.

А "эти данные" это ЧТО у вас подразумевается?
Не упускайте контекст заданного вопроса...

Кста, для ЦМСок решение гиморное но кажется есть из коробки:
http://joomlaforum.ru/index.php/topic,158734.0.html
http://blogomunity.com/joomla-extensions/a...es-manager.html
Disclaimer: "за что купил за то и продаю!" (с)
Почитайте и это тоже:
http://www.sql.ru/forum/actualthread.aspx?tid=729352
http://phpclub.ru/talk/threads/%D0%9E%D0%B...B0%D1%85.45513/

inpost полностью согласен в сесиях храню только id пользователя, остальные данные изменяемые а те которые не изменяемые проще запросить из бд

что мешает SID использовать в качестве временного пароля?

SID это sesion id?

Да. но не все так просто как кадется уважаемому инпосту...
кста, тут почитать тоде полезно имхо
http://www.instantcms.ru/blogs/myinstantcm...torizacija.html

а SID при каждой авторизации одного и тогоже пользователя меняется?

Добрый совет, БесТайм! прислушайтес к сказанному:

Для авторизации на нескольких доменах (не поддоменах 1 домена) есть 2 пути - простой и сложный.

тут говорится про разные домены а мне для основного домена и поддоменов. Я понял тебя что это надо сделать через куки, че мне для этого надо. В куки и в бд записать СИД и при заходе юзера на сайт делать куки=бд так? и это будет сто процентов безопасно?

Не получится 100% безопасности! особенно при юзании бд... всё очень непросто и сказанное челом по ссылке - это незря! И между прочим, сам я -- спец с 16-летнм стажем -- разрабатывал подобные приблуды, притом тратил на это недели, вкл-но процедуры отладки и тестирование на секурность естественно!

ну а как могут залезть в бд или подменить СИД если там непредскозуемые айдишники.

Да не залезть в БД и не сменить сид!... всё гораздо сложнее.. но нее скажешь на форуме то что тянет на книги и монографии по секурности...
(Вы же уж точно не умеете мыслить логически и всё продумать-просчитать в голове. )
Но извините, я вам не бесплатный препод для предмета интернет-секьюрити...

Если не хотите гимору и не способны сами разрабатывать высокопрофессиональные проекты - юзайте openid или аналоги, с их несложным API, и точка...

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

а как записать в куки SID?

BesTime, "совет" в ТАКИХ областях тянет хз на что и сколько...
Т.б если Вы не знаете даже как записать в куки SID...

Т.б что именно СОВЕТ я Вам дал. и не плохой... тот же факт, что он Вам не приглянулся, не отменяет пользы от оного...

я раньше не сталкивался с SID а в гугле показывает что это устанавливается в начало докумена

session_id();

А как записать полученый id в переменную я не понимаю

Ну почитайте же на php.ru или где еще о сессиях и кукисах!!!

этим и занимаюсь