Расширенный скелет проекта PHPixie с аутентификацией и админкой

    image

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



    Демо



    Итак, более подробно что у нас тут:

    • Регистрация пользователей
    • Логин с опцией «запомнить меня»
    • Проверка логина на страницах
    • Панель администратора с отдельным логином
    • Администраторы хранятся в отдельной таблице, их можно добавлять через консоль
    • Возможность администратору имперсонировать любого пользователя


    Использование
    composer create-project phpixie/project-auth project
    

    Настраиваем веб-сервер в папку project/web и готово. Один администратор уже добавлен, его логин phpixie / framework, но можно и добавить своего через консоль (к сожалению в PHPixie пока нет красивого компонента для вызова команд с консоли):
    php addAdmin.php someUser somePassword
    


    Проект настроен использовать SQLite базу данных которая лежит в database.sqlite. Вот ее структура для MySQL:
    CREATE TABLE `users` (
        `id` INTEGER AUTO_INCREMENT PRIMARY KEY,
        `email` VARCHAR(255) NOT NULL UNIQUE ,
        `passwordHash` VARCHAR(255) NOT NULL
    );
    
    CREATE TABLE `userTokens` (
      `series` varchar(50) NOT NULL,
      `userId` int(11) DEFAULT NULL,
      `challenge` varchar(50) DEFAULT NULL,
      `expires` bigint(20) DEFAULT NULL,
      PRIMARY KEY (`series`)
    );
    
    CREATE TABLE `admins` (
        `id` INTEGER AUTO_INCREMENT PRIMARY KEY,
        `username` VARCHAR(255) NOT NULL UNIQUE ,
        `passwordHash` VARCHAR(255) NOT NULL
    );
    


    Код на Github: github.com/PHPixie/Project-Auth

    Если вам интересно как выглядит работа с PHPixie загляните в этот проект и надеюсь вы приятно удивитесь.
    Поделиться публикацией

    Комментарии 37

      +2
      На будущее — не используйте регистр в именах полей, вместо userId желательно именовать поля как user_id. В некоторых реализациях БД регистр не имеет никакого значения и поля, например для пароля (password) «проверочного слова восстановления пароля» (passWord) будут идентичными. Пример конечно же излишне надуманный, но всё же правила хорошего тона и всё такое.
        0
        так в чем проблема? сама БД не позволит создать колонки password и passWord в одной таблице по той же причине
          0
          Ну и как минимум все другие орм и фреймверки хотят использовать поля именно с _, тем самым использую такую схему, человек получит геморрой при смене фреймверка.
            +1
            ммм, я вот с доктриной всю жизнь кемел кейс использую. «Все» это какие?
            0
            Правило хорошего тона в SQL базах данных.
              0
              Где такое написано?
                0
                Ниже написал причину.
            +1
            тоже ближе snake_case однако не слышал что это «правила хорошего тона» и знаю много разработчиков которые любят camelCase и в названиях таблиц и в именах полей (и ругаются на Laravel что она по дефолту работает именно со snake_case).
              0
              Snake_case это case insensitive идентификатор, все ОРМ сейчас экранируют колонки и имена таблиц — так что это не так критично, но если нужно написать запрос руками то с CamelCase возможно придется экранировать идентификаторы в зависимости от настроек базы (Postgres вроде по умолчанию все приводит в lowercase). Это просто удобнее.
                +1
                так есть куча полей которые и так придется экранировать по этой логике, например поле «name» и тд. snake_case и camelCase различаются только когда дело доходит к нескольким словам в идентификаторе
                  0
                  По какой логике? Поля приводимые к lowercase экранировать не обязательно.
                    0
                    давай лучше скинь пример запроса где это будет проблемой, а то честно в упор не пойму о чем ты
                      0

                      select name, countPurchases from users
                      что бы это заведомо завелось нужно использовать
                      select name, "countPurchases" from users.


                      snake_case отработает с и без экранирования идентификаторов на любой базе.

                        –1
                        попробовал с кавычками и без, все работает
                0
                ближе snake_case однако не слышал что это «правила хорошего тона»

                Первая ссылка в google по «sql style guide»:
                Use underscores where you would naturally include a space in the name (first name becomes first_name).
                  +2
                  Ну как бы стайлгайд од какого то чувака это не доказательство и не правило хорошего тона. В разных фирмах или сообществах свои стайлгайды. (напомню что я за snake_case, но не против camelCase)
                    0
                    Я бы не стал называть его просто «каким-то чуваком» =) Я просто привожу в пример реально существующий стайл-гайд, где четко указано использовать «underscore». И я знаю людей и команды, которые придерживаются его (за неимением официального от MySQL или PostgreSQL). По мне, так достаточно нормальный аргумент, если учесть что в поддержку CamelCase я не вижу ничего кроме вкусовых предпочтений отдельных людей.
                      0
                      Стайлгайд это просто стайлгайд а не правило хорошего тона. По такой логике можно сказать что ваш код на PSR-2 плох потому что он не по стайлгайду Зенд фреймворка.

                      Если честно я совсем не понимаю что все придрались к именам таблицы и полей, если вам никто не мешает использовать какие-себе хотите. Уже больше 20 комментов, ни один по фреймворку и коду, а все о камелКейсе
                        0

                        Так холивар же.


                        Мне больше нравится этот ответ:
                        "Being consistent is far more important that what particular scheme you use."


                        Так что для большего единообразия полей AR и кода лично я выбрал camelCase.

                          +1
                          А я считаю, что каждый язык должен использовать свой style guide. У SQL свой, у PHP свой, у JSON-API свой. У меня был случай, что мне нужно было перенести проект на другой язык. И что мне, всю схему БД менять? Или добавился второй клиент, использующий JSON-API, написанный на языке с другим стилем именования переменных.
                            0

                            У меня данные из MySQL базы данных, через Active record на PHP загружаются в объект JS и рендерятся на клиентсайде в HTML5.
                            Вопрос: какой стайлгайд мне использовать? Или на каждом уровне свой?


                            PS Использую camelCase на всех уровнях.

                              0
                              Я бы использовал на каждом уровне свой + маппинги. Потом я мог бы переименовать хоть все поля в БД, и мне не пришлось бы менять ни строчки в JS.
                          0
                          Если, как вы заметили, многие сделали вам замечание по поводу имен полей — так, может быть, действительно что-то не так?

                          P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
                            0
                            так для SQLа какой? Лично я люблю кемелкейс потому что я могу сразу с БД отправлять в джаваскрипт где и так все камелкейсом.
                              0
                              Так хотя бы вот этот. Это более-менее распространенный, хорошо оформленный стандарт.

                              сразу с БД отправлять в джаваскрипт

                              А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
                              ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
                  –3

                  Всегда было интересно посмотреть список этих "некоторых БД", где проблема с camalCase, чтобы никогда с ними не сталкиваться.

                    0
                    sqlite, mysql, наверняка ещё какие-нибудь.
                    пруф

                      0
                      В MySQL кстати флаг есть который вырубает это.
                        –2

                        Ну так оттюнить можно по-разному почти что угодно, наставить плагинов, ещё чего-нибудь. Не суть.


                        Более жизненный пример: Напишет кто-то поле userName с камелкейсом в БД, а внутри самого кода другой человечек будет писать $entity->username, потом окажется что потребуется переезд на новую БД, т.к. этот сервак сгорит к чертям (у меня такое было, когда БД повреждалась, благо реплика была). А там этот флаг стоит и весь код накрылся, догадывайся только почему username не отображается (значение null в популярных AR для доступа к неизвестным полям моделей). Удачной отладки, называется. Ну а в случае выборки SELECT username FROM ... — вообще все запросы накроются, т.к. мол поле username не найдено.


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

                          0
                          ну уж если говорить о переезде с одного конфига на другой так тут историй можно еще хуже понапридумывать. Суть проста: большинство БД не чувствительны к регистру, камелкейсу это никак не мешает если писать нормальный код а не «uSerNAme», а если писать фиг знает что то проблемы будут везде
                        –1

                        Работаю с mysql поля в camelCase и не было проблем.
                        Вопрос: что я делаю не так?

                    +1
                    В постргесе будут проблемы: Таблицу можно создать как «TeSt1», а попытаться использовать как select * from test1. Будет ошибка «ERROR: relation „test1“ does not exist LINE 1: SELECT * FROM test1»
                      +1
                      так а зачем использовать другое имя?
                        0
                        В том то и суть, что оно другое только за счет регистра. Масса примеров, когда можно попасть на ошибки. Например, когда код не использует автоматическое заключение в кавычки, или запросы написаны напрямую, Зачем создавать потенциальные проблемы, если можно этого избежать, следуя соглашению о не-использовании в бд кемелкейса?
                          0
                          P.S. Привычка не-использовать кемел-кейс в моем случае выработалась не в результате чтения код-стайлов, а как раз после многократного выяснения, почему не работает вроде бы правильно написанный код.
                          –1

                          Ога ога......


                          Расскажите это разработчикам на JS: согласно code conventions там переменные и функции надо называть в camelCase, а переменные TeSt1 и test тоже внезапно будут разные.

                            0
                            Простите, а причем тут js? В php и js я тоже за camelCase, но как это связано?

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое