2010-05-18 3 views
9

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

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

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

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

Кроме того, в идеале, я хотел бы предоставить U только права на просмотр модели A (так что не добавлять, удалять или изменять только), но я читал об этом (странно, если вы меня спрашиваете) к которому «Если вы не доверяете U, просто запретите ему доступ к области администрирования вместе». Вид глупой доктрины.

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

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

Заранее благодарен!

+0

Большой вопрос здесь: как вы определяете этот «пользователь X имеет доступ только для чтения к объектам Y»? Структура perms является скорее базой, на которой вы должны написать свой собственный код, чтобы проверять и проверять действия пользователей на определенных объектах. Прочтите [decor_required] [1] декоратор, чтобы узнать больше. Сам админ не будет волноваться, что пользователь X не может создать объекты Y и впоследствии удалить параметр «Добавить Y». [1]: http://docs.djangoproject.com/en/1.2/topics/auth/#django.contrib.auth.decorators.permission_required – dguaraglia

+0

было бы легче прочитать вопрос, если бы у вас были образцы моделей и классы modeladmin –

ответ

2

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

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

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

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

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

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

Смежные вопросы