Ребята, в некоторых регионах нашей необъятной страны уже начался наш с Вами день, 256-й день в году, День Программиста! Поздравляю всех, добра всем, заказов хороших, интересных, заказчиков щедрых, адекватных, работы много, ровно как и отдыха! Всем всего-всего-всего! Поздравляю администрацию от всей души! Именно благодаря им я пишу сейчас здесь, и имею честь знать прекрасных специалистов и просто приятных людей, с которыми познакомился на этом форуме. Уррраааа!!
После продолжительного холивара у меня вопрос: чем мой вариант-таки не устроил? Или все же ТС пишет авторизацию на веримегахайлоад, на котором один запрос к базе при одном обращении к скрипту - непосильный груз?
Очень-очень-очень плохо искали.
В файле php, назовем его script.php, пишете функцию, назовем её load().
В файле html, назовем его index.html, пишете конструкцию:
Имена файлов и функций, ессесно, на Ваш вкус. Этот вариант сработает, если скрипт с html-файлом лежат в одном каталоге. Если нет - читайте учебники, это самое элементарное.
Глумись - не глумись, а конкретики все равно никогда не добьешься. Вы со своего сайта данные получаете? Как? Прямой доступ к базе есть, в которой Ваши ID с названиями? Если нет, то как получаете? API у удаленного сайта есть? Что значит
Hays пишет:
на другом сайте есть скрипт, которое по id проверяет
Ну в куке у меня токен, а не пароль и даже не его хэш.
LIME пишет:
зачем проверять пароль на каждый запрос если мы уже его проверили и на основании этого создали сессию
0. Сессии не люблю
1. Сессию подменить проще, чем запись в БД (особенно на хостингах)
2. Вдруг я его снесу, а он будет залогинен до истечения времени сессии.
Когда проходит процесс авторизации, нужно сделать выборку из базы, чтобы проверить пароль. Заодно выберите и все данные юзера, которые могут пригодиться в дальнейшем, и держите их свойствами класса / массивом. В любом месте приложения (авторизация все равно должна быть выше мест, в которых понадобятся различные данные пользователя, по логике, иначе приложение кривое) пишете что-то типа $user->email - вот Вам и email, $user->hash - вот Вам и хэш пароля. Это при авторизации.
Потом, при каждом запросе к движку в любом случае должна проходить аутентификация, при которой все равно придется лезть в БД за хешем пароля (либо токеном), делаете то же самое, что я описал выше.
P.S. Я сессиями вообще не пользуюсь, у меня везде авторизация устроена так:
Авторизация: (цель - поставить токен, либо отправить обратно к форме)
Приходит POST из формы входа
Идем в таблицу users базы данных, выбираем все поля, включая хэш, соль, мыло, имя, фамилию, и т.д., складываем это в массив $user->data
Проверяем на соответствие данные из POST с данными из БД
Если все совпало, добавляем токен в таблицу tokens, который содержит сам токен + IP + UA + ID пользователя + Кол-во неудачных попыток входа + можно ещё чего-нибудь придумать
Ставим куку с самим токеном
На всякий случай убиваем $user->hash и $user->salt, они нам больше не нужны
Аутентификация: (цель - проверить токен и узнать, что за пользователь тут)
Смотрим в куку
Идем в таблицу tokens базы данных, выбираем все поля
Проверяем на соответствие данные из POST+$_SERVER с данными из БД
Если все совпало, делаем выборку из users, собираем в массив $user->data
При этом у меня аутентификация проходит вообще при каждом обращении к движку, даже при авторизации, т.е., сам процесс авторизации только лишь проверяет пару логин-пароль и ставит токен. При таком подходе очень удобно хранить данные в объекте User, никаких файлов и сессий. Выборка из базы два раза при авторизации и один раз при обычной работе приложения.
Да любой хостер выгонит Вас нафиг, когда узнает, что Вы собрались делать.
В прошлый раз не стал говорить, сейчас скажу. Я в свое время сдал около трех дюжин сайтов для "простых предпринимателей". Красивые сайты на удобном движке. Пусть процедурный, пусть в коде черт ногу сломит, но работает без косяков. Это я к чему. Я ненавижу работать с контентом, думал, сдам проект, денежки получу и готово. А хрен. Ни один из них не ведет свои сайты, я все делегировал девочкам-фрилансерам. Последним плевать, где и как сделан сайт (а точнее, им ещё и лучше, если сайт на джумле/друпале/и т.д., т.к. они с ними знакомы).
Стандартный разговор с заказчиком во время сдачи проекта:
- Так, а че пусто?
- В смысле?
- Ну где "О нас", Галерея", "Прайс"... ?
- Ну у нас же есть ТЗ, по которому я Вам сделал замечательнейшую удобную систему управления, чтобы Вы сами заполняли и вели сайт! Вам не придется платить за содер...
- Э-э, стоп. Я не хочу сам заполнять, а сотрудникам в штате некогда, у них своя работа. Есть кто-то на примете?
И т.д. Так было каждый раз. А фирма, которая может позволить себе в штат работника, который будет вести сайт, никогда не сделает сайт на бесплатном сервисе. Ни-ког-да. Тем более, как уже писал ув. caballero
caballero пишет:
многие хостеры предлагают уже предустановленные CMS на выбор.
Взял хостинг -> нажал кнопку -> готово.
Либо остаются 5% горе-предпринимателей-неадекватов, которые потом положат Ваш саппорт-номер на долгие месяцы, пока не сдуетесь. И постоянными клиентами будет порнуха, торренты, говнокод-чаты, которые положат свой сайт и все остальные Ваших клиентов (кластеризовать-то никак), и т.д.
И забудьте про хостинг. Эти задачи не решаются на хостингах. Это как минимум неудобно, как максимум - невозможно. Тем более, что хороший хостинг стоит дороже, чем самый простой сервер у хайцнера. А плохой хостинг - можете и не начинать.
seowor пишет:
но ищу также и без рассходов для отработки кода
Я Вас умоляю, 10 рублей в день это расходы? Тем более, что при Вашем уровне подготовки Вам все равно Ваш отлаженный на локалке код после переноса на сервер даст дрозда.
Вот правда, от всей души желаю процветания, серьезных и прибыльных проектов, но пока все несерьезно совершенно.
Относительно поста выше про то что если на сервер будет монитор то ничему не научитесь это полнейшая чушь
Да Вы что... Если Вы всему из гуя научились, молодец. Однако, чтобы быть хорошим администратором, умение делать из консоли все, что можно сделать из интерфейса, плюс чего нельзя сделать из интерфейса, обязательно. А парень сейчас поставит убунту на домашнем компе, откроет синаптик, поставит из него ламп, в лучшем случае поставит Iptadmin, и будет доволен, что все работает. А случись аварийная ситуация, ничего сделать не сможет, потому что не знает, как работает терминал.
Dragon_Knight пишет:
Есть здравый смысл и следовать нужно ему а не моде..
Я не модник, у меня нет айфона, я одеваюсь не в брендовые вещи, нет инстаграма и вибера, а в консоли я работать умею. Слава Богу, что мне здесь таких советов не давали, а неоднократно помогали и до сих пор помогают разбираться с дебрями Debian.