Разрешения пользователя Django Inlines + только просмотр - проблемы с разрешениями

Я не уверен, что это ошибка или я просто что-то упускаю (хотя я уже разобрал документацию по инлайнам), но:

Допустим, у меня есть модель A. Модель A является встроенной моделью B. Пользователь U имеет полный доступ к модели B, но изменяет только разрешения на модель A (поэтому ни добавлять, ни удалять).

Однако при редактировании модели B пользователь U по-прежнему может видеть ссылку «Добавить другую A» внизу, хотя у пользователя U нет разрешений на добавление для этой соответствующей модели.

Что случилось? Почему эта ссылка продолжает показываться? Моя логика говорит, что если у U нет разрешений на добавление A, ссылка больше не должна появляться.

Также, в идеале, я хотел бы дать U только права просмотра модели А (так что никаких добавлений, удалений или изменений - только просмотр), но я читал о той (странной, если вы спросите меня) философии, согласно которой "Если вы не доверяете U, просто запретите ему доступ к админке вообще». Какое-то глупое учение.

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

Как средний программист Django, такой как я, получает разрешения только на просмотр и, прежде всего, как мне избавиться от ссылки «Добавить еще один A» в нижней части формы редактирования администратора?

Заранее спасибо!


person Vali    schedule 18.05.2010    source источник
comment
Большой вопрос здесь: как вы определяете, что этот пользователь X имеет доступ только для чтения к разрешениям объекта Y? Фреймворк perms — это скорее база, на которой вы должны написать свой собственный код для проверки и проверки действий пользователя на определенных объектах. Узнайте больше о декораторе [permission_required][1]. Сам администратор не будет волшебным образом догадываться, что пользователь X не может создавать объекты Y, и впоследствии удалить опцию «Добавить Y». [1]: docs.djangoproject.com /ru/1.2/topics/авторизация/   -  person dguaraglia    schedule 04.06.2010
comment
было бы легче читать вопрос, если бы у вас были образцы моделей и классы modeladmin   -  person Skylar Saveland    schedule 26.06.2010


Ответы (1)


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

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

Единственный способ, которым я вижу, что вы можете иметь такой большой контроль в админке, это не встраивать A.

«Если вы не доверяете U, просто запретите ему доступ к админке вообще». Какое-то глупое учение.

Не совсем, если учесть, что администратор не предназначен для обеспечения необходимого уровня усиления безопасности, чтобы гарантировать этот точный уровень контроля доступа. Из-за его открытого и расширяемого характера в админке есть много-много мест, где могут скрываться ошибки (обычно в коде, написанном пользователем), которые могут быть использованы злоумышленниками. Вот почему ненадежные пользователи всегда должны видеть, что все URL-адреса администратора возвращают 404.

В любом случае, когда требования к управлению доступом настолько детализированы, маловероятно, что общее (то есть django.contrib) решение подойдет.

person Mike DeSimone    schedule 22.06.2010