Перейти к содержанию
Официальный форум поддержки Simpla

Вопрос: Авторизация Admin как пользователь


Рекомендуемые сообщения

Никак не могу разобраться, как при нынешней авторизации администратора (site.com/simpla), сделать, чтобы авторизация проходила как у обычного пользователя с главной страницы сайта?

Изменено пользователем alexivchenko
Ссылка на сообщение
Поделиться на другие сайты

Никак не могу разобраться, как при нынешней авторизации администратора (site.com/simpla), сделать, чтобы авторизация проходила как у обычного пользователя с главной страницы сайта?

Никак, это абсолютно разные авторизации.
Ссылка на сообщение
Поделиться на другие сайты

Никак не могу разобраться, как при нынешней авторизации администратора (site.com/simpla), сделать, чтобы авторизация проходила как у обычного пользователя с главной страницы сайта?

 

Для этого надо переделать всю схему авторизации админа - по образцу авторизации пользователя. Довольно хлопотно. А вообще по-хорошему это должно быть стандартно...

Ссылка на сообщение
Поделиться на другие сайты

 

Для этого надо переделать всю схему авторизации админа - по образцу авторизации пользователя. Довольно хлопотно. А вообще по-хорошему это должно быть стандартно...

Я так понимаю нужно сделать роли, по типу групп - администратор, менеджеры и пользователи.

В базе у пользователя сделать role (1) админ, (2) менеджер, (3) пользователь. Пользователь при регистрации получает (3). Менеджера назначает администратор. Админ получает либо при установке, либо ручками в базе. В админ панели управляем ролями с доступом.

Далее делать проверку сессии по номеру роли, если 1 и 2 допускаем к админ.панели.

Ссылка на сообщение
Поделиться на другие сайты

Можно и так.

Но обычно для пущей безопасности админов и пользователей в одну кучу (одну таблицу) не пихают, а делают для них отдельные таблицы и отдельные скрипты авторизации...

Ссылка на сообщение
Поделиться на другие сайты

Серверная авторизация намного надёжней чем хранение админа в БД...

Даже у нашумевшей окайцмс авторизация не очень надёжная.

Ссылка на сообщение
Поделиться на другие сайты

Большинство CMS, насколько я знаю, уже много лет хранят админа именно в таблице БД. И особых проблем с безопасностью не наблюдается.


А вот у Simpla в этой части сделано явно хуже, чем у прочих.

Видимо, объяснения этому можно найти в истории:

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

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

3. В итоге попали в тупик. Ибо развиваться тут некуда, можно только почти все заново программировать.

4. И по многим позициям у Simpla картина подобная. Думаю, автор это сознает, и потому систему развивать не хочет - чувствует, что ничего хорошего не получится...

Ссылка на сообщение
Поделиться на другие сайты

Большинство CMS, насколько я знаю, уже много лет хранят админа именно в таблице БД. И особых проблем с безопасностью не наблюдается.

Авторы систем также морально устарели как и ты.

Ты не идёшь в ногу со временем, тебе достаточно строчить "код" в notepad++...

P.S. Старый запорожец уже и не сыскать, но он есть и даже едет.

Ссылка на сообщение
Поделиться на другие сайты

Авторы систем также морально устарели как и ты.

Ты не идёшь в ногу со временем, тебе достаточно строчить "код" в notepad++...

P.S. Старый запорожец уже и не сыскать, но он есть и даже едет.

Артём, объясните. Чем нынешняя авторизация админа лучше, чем сделать ее как у пользователя.

Ссылка на сообщение
Поделиться на другие сайты

Артём, объясните. Чем нынешняя авторизация админа лучше, чем сделать ее как у пользователя.

Вероятность подбора логина\пароля сводится к нулю.
Ссылка на сообщение
Поделиться на другие сайты

Вероятность подбора логина\пароля сводится к нулю.

 

Очень интересно:

1. Что значит "сводится"?

2. Что значит "сводится к нулю"?

3. Как считается вероятность при серверной авторизации?

4. Как считается вероятность при принятой в большинстве CMS через хранение данных в БД?

5. Почему вероятность п.3 сводится именно к нулю?

6. К чему сводится вероятность п.4?

 

Что-то не видно в Сети массовых жалоб он владельцев CMS, что у них подобрали логин-пароль...

 

https://zen.yandex.ru/media/ger/kak-hakery-vzlamyvaiut-paroli-maksimalno-prosto-5d666e6e0ef8e700adde3d10

Ссылка на сообщение
Поделиться на другие сайты

Давайте посмотрим немного с другой стороны на ситуацию - симпла делалась как максимально простое решение, решение в которое каждый сможет допилить то что ему нужно.

 

В итоге имеем - почти каждый сайт на симпла делали 2-3-5 кодеров, каждый вносил что-то свое, как следствие накопление ошибок (да-да), и если админка будет "там же" где и остальной код вероятность что система станет дырявой стремиться к бесконечности с каждой правкой. По этому закрытие админки серверной авторизацией ни что иное как "защита от дураков" в лице криворуких кодеров, и их программистов.

 

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

Ссылка на сообщение
Поделиться на другие сайты

Очень интересно:

1. Что значит "сводится"?

2. Что значит "сводится к нулю"?

3. Как считается вероятность при серверной авторизации?

4. Как считается вероятность при принятой в большинстве CMS через хранение данных в БД?

5. Почему вероятность п.3 сводится именно к нулю?

6. К чему сводится вероятность п.4?

 

Что-то не видно в Сети массовых жалоб он владельцев CMS, что у них подобрали логин-пароль...

 

https://zen.yandex.ru/media/ger/kak-hakery-vzlamyvaiut-paroli-maksimalno-prosto-5d666e6e0ef8e700adde3d10

Корс ты больной параноик
Ссылка на сообщение
Поделиться на другие сайты

Давайте посмотрим немного с другой стороны на ситуацию - симпла делалась как максимально простое решение, решение в которое каждый сможет допилить то что ему нужно.

 

В итоге имеем - почти каждый сайт на симпла делали 2-3-5 кодеров, каждый вносил что-то свое, как следствие накопление ошибок (да-да), и если админка будет "там же" где и остальной код вероятность что система станет дырявой стремиться к бесконечности с каждой правкой. По этому закрытие админки серверной авторизацией ни что иное как "защита от дураков" в лице криворуких кодеров, и их программистов.

 

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

 

Большинство CMS имеет открытый код, в который владельцы могут вносить правки и и они их реально активно вносят. Однако разработчики CMS не считают нужным использовать именно серверную авторизацию. Видимо, потому, что текущий уровень безопасности всех устраивает. А количество разработок и разработчиков в некоторых системах, например, OpenCart, превышает аналогичные показатели Simpla в десятки раз.

 

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

Ссылка на сообщение
Поделиться на другие сайты

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

Ссылка на сообщение
Поделиться на другие сайты

Не забывайте про изначальную концепцию симплы.

А можно где-то прочесть официальную информацию про изначальную концепцию симплы? Дайте ссылочку, пожалуйста...
Ссылка на сообщение
Поделиться на другие сайты

 

А можно где-то прочесть официальную информацию про изначальную концепцию симплы? Дайте ссылочку, пожалуйста...

Маразм Корса всё крепчает : facepalm:

Ссылка на сообщение
Поделиться на другие сайты

А можно где-то прочесть официальную информацию про изначальную концепцию симплы? Дайте ссылочку, пожалуйста...

simplacms.ru

Ссылка на сообщение
Поделиться на другие сайты

http авторизация:

+ она закрывает всю бекенд директорию от лишних запросов

+ исходя их первого уменьшается необходимость жестко контролировать объекты бекенда

+ безопасность на хорошем уровне

- данные об менеджере ограничены и проблемно связываются с остальной базой данных

- при попадании в админ-часть, даже с минимальными правами, нам становятся доступны запросы на сторонние объекты (у которых может быть неконтролируемый функционал)

 

бд авторизация:

+ данные менеджера легко расширяются и связываются с другими данными  

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

+- уровень безопасности зависит от пункта выше

 

способ авторизации зависит в первую очередь о целей для которых эта авторизация делается. Если она несет чисто доступный функционал - вполне достаточно http.

 

 

Автору темы: 

при создании изменении менеджера - создавайте изменяйте обычного пользователя. Связь пользователь=менеджер сделайте через запись ида пользователя в .passwd

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

Изменено пользователем yr4ik
Ссылка на сообщение
Поделиться на другие сайты

Термин "концепция" -  на мой взгляд, слишком громко сказано для небольшого описания отдельных моментов.

 

А бонусом там идет утверждение "на большинстве страниц магазина используется не более десяти SQL-запросов", которое совсем НЕВЕРНОЕ:

http://forum.simplacms.ru/topic/8549-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D1%8B-sql-%D1%80%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D0%B0-%D0%B8-%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C/?hl=%2B%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D1%82%D1%81%D1%8F+%2B%D0%B1%D0%BE%D0%BB%D0%B5%D0%B5+%2B%D0%B4%D0%B5%D1%81%D1%8F%D1%82%D0%B8+%2Bsql-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2

 

Если цитированное утверждение тоже входит в концепцию, то это не повышает уровень доверия к такой концепции...

Изменено пользователем phukortsin
Ссылка на сообщение
Поделиться на другие сайты

http авторизация:

+ она закрывает всю бекенд директорию от лишних запросов

+ исходя их первого уменьшается необходимость жестко контролировать объекты бекенда

+ безопасность на хорошем уровне

- данные об менеджере ограничены и проблемно связываются с остальной базой данных

- при попадании в админ-часть, даже с минимальными правами, нам становятся доступны запросы на сторонние объекты (у которых может быть неконтролируемый функционал)

 

бд авторизация:

+ данные менеджера легко расширяются и связываются с другими данными  

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

+- уровень безопасности зависит от пункта выше

 

способ авторизации зависит в первую очередь о целей для которых эта авторизация делается. Если она несет чисто доступный функционал - вполне достаточно http.

 

 

Автору темы: 

при создании изменении менеджера - создавайте изменяйте обычного пользователя. Связь пользователь=менеджер сделайте через запись ида пользователя в .passwd

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

 

Спасибо за рекомендацию (попробую), сейчас делаю локально и проверяю пока с ролями (1.2.3)

В административной панели проверяю на доступ по цифре в строке базы role

Прямого доступа к site.com/simpla нет, чтобы убрать её из robots.txt и при определении возможности доступа к административной части на главной странице сайта появляется ссылка "АдминПанель" 

Ссылка на сообщение
Поделиться на другие сайты

Большинство CMS, насколько я знаю, уже много лет хранят админа именно в таблице БД. И особых проблем с безопасностью не наблюдается.

 

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

Ссылка на сообщение
Поделиться на другие сайты

 

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

 

Что хотите сказать этой странной фразой?

 

Я тоже не прошу у владельцев сайтов на Simpla доступ админа. А еще я не прошу паспорт владельца. И не спрашиваю девичью фамилию бабушки. И еще не требую сотни разных сведений. Но благополучно могу делать в админке все что нужно...

 

Очень сомневаюсь, что Ваш волшебный батник дает Вам доступ к любому сайту на bitrix по одному лишь URL...

Ссылка на сообщение
Поделиться на другие сайты

Что хотите сказать этой странной фразой?

 

Я тоже не прошу у владельцев сайтов на Simpla доступ админа. А еще я не прошу паспорт владельца. И не спрашиваю девичью фамилию бабушки. И еще не требую сотни разных сведений. Но благополучно могу делать в админке все что нужно...

 

Очень сомневаюсь, что Ваш волшебный батник дает Вам доступ к любому сайту на bitrix по одному лишь URL...

 

на симпле проще имея доступ к фтп в simpla добавить пользователя в  .passwd или переместить в другую папку вместе с .htaccess.  В битриксе не прокатит так тк пароли и пользователи хранятся в бд

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
×
×
  • Создать...