Добавлено: 01/05/04 в 21:18

Хотел бы услышать мнения по сабжу , программистов местных (проффесионалов) , куда не глянь в партнерках на платниках , везде
авторизация через Апачу , может ли авторизация через сессии в пхп составить конкуренцию , если нет плиз объясните почему , я думаю что может, но возможно не знаю всех мелочей и реальных обстоятельств так сказать.Спасибо.

Добавлено: 01/05/04 в 21:41

Я так понимаю, что под авторизацией через Апач не имеется ввиду файлы .htpasswd итд. Тоесть авторизация просиходит все-таки через PHP
который выдает header: 403 (не авторизирован) и клиенту предлагается ввести логин с паролем в стандартное окошко апача.

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

Теперь насчет сессий у PHP (session_start, session_init...). Я вообще не считаю, что их реализация хороша. Смысл их в том, что весь гемор с сессиями на себя берет PHP, а программеру остается тока написать session_start. Это в общем их главный минус. Я люблю полный контроль над происходящем, поэтому не использую такой вариант.

Сессии можно делать самому. По хорошему после каждого логина, юзеру генерится номер сессии (хранится в БД), и клиенту отдается либо кука с этим номером, либо номер прописывается в URL (как на старом mail.ru - хttp://mail.ru/НОМЕР_СЕССИИ/скрипт).
Этот способ хорош тем, что настравивать эти сессии прогрмер может как хочет.. устанавливать время жизни, вести полную историю по входам-выходам.
В идеальном случае лучше выдавать номер сессии через URL, потому что куки не у всех включены, да и есть способы украсть куку у пользователя в то время пока сессия еще не истекла. Через URL надежнее IMHO.
Что и говорить, - с сессиями необходимо авторизовывать юзера по комбинации номер_сессии, ip_адрес (плюс всевозможные прокси сюда же) и по времени жизни сессии.

Если говорить о проблемах сессий, то диалапщики обладатели ящиков на yandex.ru меня поймут. Пишите вы письмо, долго долго (час, два), а потом рвется конект, и бляндекс вас попросит вежливо авторизоваться еще раз. Не факт, что недописаное письмо останется.

Вывод таков- для разных нужд используйте свои подходы. Если у вас сайтик в интранете, где вы обмениватесь сообщениями с сотрудниками, то можно авторизовывать Апачем (конечно с SSL-enabled). Если говорить о партнерках, то это дело предпочтения программиста. Если это огромный веб проект, то нада делать сессии, причем очень грамотно..


IMHO. Объяснил как смог

Последний раз редактировалось: undef (01/05/04 в 21:52), всего редактировалось 1 раз

Добавлено: 01/05/04 в 21:50

Авторизация апачем более простая и быстрая.
php сессиями геморойней, но более гибче. Вобщем кому как нравится. Я везде сессии стараюсь использовать.

Добавлено: 01/05/04 в 21:55

Спасибо ответы кто еще что может сказать по сабжу.
Я наверно немного неверено поставил вопрос , во-первых по поводу безопасности хотелось бы узнать : хаку , подборке паролей и т.п.
эти маханизмы одинаковы по возможности противостояния к этим делам ?если учесть со стороны сессий вышеописанные методы (ид сессии в базе, детект по ай-пи).

Добавлено: 02/05/04 в 18:08

Теперь буду сказать я.

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

Рекомендую использовать сессии при авторизации посредством PHP для того, чтобы не дергать базу на каждый запрос юзера(про то, чтобы не хранить данные об авторизации в куке, я уже выше написал). В сессии храним инфу об авторизации, и работа скрипта значительно ускоряется.

А метод авторизации через Basic-Auth или ввод пароля в форме в этом конкретном случае никаких различий не имеет(различие только в самом окошке где пароль вводится).

Добавлено: 02/05/04 в 19:35

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

Добавлено: 02/05/04 в 22:54

Почти всегда пишу собственный код управления сессиями, авторизации и т.п.
Ничего сложного в нем нет, а когда есть наработки - вообще элементарно.
Вариантов в общем-то всего 3 (не считая комбинированных и апачи):
- сессия на основе ip. Безопасность не на высоте (с того же ip будет видно все еще некоторое время), но и сломать вообще-то нельзя, только случаи когда сразу за юзером юзают юзерский комп или совпадения диалаповских ip у провайдера. На массовых сервисах по этой причине лучше не юзать. Ну и конечно при разрыве накрывается пиздой - тоже неприятно.
- сессия через куки. Самый реальный вариант, последнее время в основном только его юзаю. Соответствующими настройками достигается хорошая безопасность, подделать даже 10-буквенный ид в куке нереально.
- сессия через урлу. То же что и с куками, но юзается mod_rewrite или path (я обычно второе юзаю - удобнее). Самый рабочий вариант, но минусы в том что остаются урлу в логах (правда кто-то и куки ухиряется логить) и немного коверкает адрес.

Впрочем, это от конкретных целей зависит, что лучше. Где безопасность - там ssl со всякими-всякими фичами, а где мало значит приватность или просто юзеры с мозгами ходят - можно спокойно использовать более простые методы.

Добавлено: 02/05/04 в 23:26

Спасибо всем за высказанные мнения , теперь все понятно и сомнений не осталось по этому поводу . Ответы оценил ;)

Добавлено: 03/05/04 в 04:18

К вышесказанному еще добавлю:
Куку (да и вообще любую инфу, за которую беспокоишься) нереально подделать, если добавить туда еще собственным способом подсчитанное ЦРЦ по переменным, загоняемым в куку.
Т.е. загоняешь в длинную строку все переменные и значения, считаешь контрольную сумму (с длинным salt-ом) по строке. Загоняешь эту переменную тоже в куку. Обратное действие понятно.

Добавлено: 03/05/04 в 18:30

sAx, я бы так категорично не утверждал.
Имея 10 вариантов строк с соответствующими crc, можно создать алгоритм(отличный от твоего, но тем не менее он будет работать). Конечно, работа не для лоха, но возможность имеется.

Если в алгоритме использовать какие-то персонифицированные данные из базы, то да, восстановить будет скорее невозможно. Но мы опять пришли к тому, что дергаем базу.

Добавлено: 03/05/04 в 21:54

Подобрать crc или md5 - тут легче сам сервер взломать, чем столько гемороится.

Добавлено: 04/05/04 в 00:40

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

Добавлено: 05/05/04 в 02:17

Разве я где-то написал "подобрать"?
И добыть 10 вариантов не проблема - у тебя ведь публичная система.

Добавлено: 08/05/04 в 01:52

Если реализовать нормально можешь, в смысле без корявости, то конечно PHP лучше, даёт больше контроля над авторизацией.

Добавлено: 20/05/04 в 19:42

Беда большинства "авторизаций на ПХП" в том, что програмер ленится и хранит логин и пасс в мускуле. В этом случае форма ввода паролей является дверкой для получения рута в мускуль. Технология мне не известна, но знакомые кулхацкеры продолжеют успешно ей пользоваться.

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

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