Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Кроссайтовая авторизация. Как?

369
09 июня 2010 года
Kesano
451 / / 09.10.2007
Друзья, нужен ваш совет по тому, как организовать кроссайтовую авторизацию на своих ресурсах...

Например:
есть домен domain.ru
и субдомены:
site.domain.ru
test.domain.ru
sub.domain.ru

Ну и соответственно мне нужно передовать данные об авторизации между ними.
Искренне мечтаю делать это с помощью сессий. Но вижу пока только один выход: Куки. Однако у некоторых пользователей куки могут быть просто отключены.
База пользователей едина для всех сайтов а-ля passport.domain.ru

Тырнет порыл на данную тему, но однозначного ответа не нашёл... Все тыкают в OpenID или в куки...
1
09 июня 2010 года
kot_
7.3K / / 20.01.2000
Наиболее правильным пожалуй является openID. Можно так же - если сайты находятся на одном хостинге делать общую таблицу пользователей. Так же для некоторых движков (Drupal например) для этих целей служит специальный модуль.
369
10 июня 2010 года
Kesano
451 / / 09.10.2007
Я не использую готовые движки, религия не позволяет...
А вот по поводу openID - это конечно хорошо, но меня интересует СВОЯ база пользователей...

Прочёл советы переноса сессий средствами сервера, жаль на виртуальном хостинге такого доступа к апачу не имею...

Куки?...
Или вообще забить болт... У гугля на каждом сервисе нужно отдельно авторизироваться...
6
10 июня 2010 года
George
4.1K / / 05.01.2007
Цитата: Kesano

Куки?...


Как Вы изволили заметить выше, куки могут быть отключены.

Цитата: Kesano

Или вообще забить болт... У гугля на каждом сервисе нужно отдельно авторизироваться...


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

369
10 июня 2010 года
Kesano
451 / / 09.10.2007
:)... Ну, я пока ещё не гугль...

Подскажите, как можно нереносить PHP-SESSION средствами php.ini
Есть доступ к php.ini и возможность настроить его под себя...
1
10 июня 2010 года
kot_
7.3K / / 20.01.2000
Цитата: Kesano
Я не использую готовые движки, религия не позволяет...
А вот по поводу openID - это конечно хорошо, но меня интересует СВОЯ база пользователей...


Ну так вроде так и просится - сделайте единый центр авторизации - т.е. авторизация/проверка прав будет выполнятся к нему. В чем проблема то?

369
10 июня 2010 года
Kesano
451 / / 09.10.2007
Я просто плохо представляю себе схему этих обращений.
для сайтов логин\пароль будут едины... И работать будут с одной базой...
А вот как сделать, что если посетитель залогинился в одном из сервисов, он, при переходе на другой сервис был автоматически залогинен в нём...

Кстати, гугол и сам оставляет кукисы...

Как вижу, всё упирается в них... Блин )))
1
11 июня 2010 года
kot_
7.3K / / 20.01.2000
Цитата: Kesano
Я просто плохо представляю себе схему этих обращений.
для сайтов логин\пароль будут едины... И работать будут с одной базой...
А вот как сделать, что если посетитель залогинился в одном из сервисов, он, при переходе на другой сервис был автоматически залогинен в нём...

Кстати, гугол и сам оставляет кукисы...

Как вижу, всё упирается в них... Блин )))


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

369
11 июня 2010 года
Kesano
451 / / 09.10.2007
быть может ты прав, кот... Только одна проблема...
Дйствовать будет только в субдоменных зонах... если урл не субдоменный - авторизируйтесь заново...
Думаю на предмет передачи некоего ключа...
Допустим идентификатор сессии который хранится на сервере в базе...
Передавать методом GET - слишком явно...
Какие могут быть варианты?
6
11 июня 2010 года
George
4.1K / / 05.01.2007
А че явно? Передают же люди, и ниче. :)
369
11 июня 2010 года
Kesano
451 / / 09.10.2007
Тогда опять же нужны советы по организации...
Как я это вижу:
После авторизации в таблицу authorized добавляется запись с id юзера, временный ключ и ip-адрес, например... И в ссылках перехода с проекта на проек передевать в GET ?logged=ED12FE34968ABED12511235...
Если ip у человека маскарадный, то перехватив (передав по аське, случайно скопипастив ссылку и .тд.) ключ человек будет авторизирован с другого компа...
Или предлагать ввсети только пароль, указав что вход выполнен в учетную запись vasya_pupkin ?...
13
11 июня 2010 года
RussianSpy
3.0K / / 04.07.2006
Я не понимаю причин спора господа. Куки для поддоменов задаются просто параметром.

 
Код:
setcookie('SID', '1234567890', time()+3600, '/', '.domain.ru');


http://www.php.net/manual/en/function.setcookie.php


А ежели у юзера куки отключены - так он нигде не залогинится и это уже его проблемы.
1
11 июня 2010 года
kot_
7.3K / / 20.01.2000
Да и тут вообще достаточно сложно давать советы - лучше посмотреть используемые решения (например в том же drupale - будь он неладен) - для того и существует open source. Если нет собственных стоящих идей, лучше попытаться грамотно копировать чужие, чем изобретать собственные лисапеды с квадратными колесами. :)
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог