Вопрос

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

У меня возникли проблемы с предоставлением анонимным пользователям доступа к содержимому узла в Drupal 6.15.Я перепробовал все, включая вставки в MySQL, проверку и перепроверку всех доступных настроек разрешений (да, я включил «Доступ к содержимому»), восстановление разрешений и очистку кеша.Я отключил пользовательские модули в надежде устранить конфликт, но все равно безуспешно.Анонимные пользователи видят страницу «Доступ запрещен» везде, кроме настраиваемой страницы просмотра календаря.

Я пробовал эти запросы, но они просто дублируют то, что уже есть:

INSERT INTO users (uid, name, mail) VALUES (0, '', '');
INSERT INTO users_roles (uid, rid) VALUES (0, 1);
INSERT INTO node_access VALUES (0, 0, 'all', 1, 0, 0);

Мой единственный проблеск надежды:Экран «Разрешения на доступ пользователя» в модуле разработки действительно показывает, что пользователь: Anonymous не может просматривать контент (СМ. ИЗОБРАЖЕНИЕ).Возникает загадочный вопрос:как получается, что «Все пользователи могут просматривать все узлы», в то время как пользователь: Анонимный одновременно имеет «НЕТ: доступ к контенту» ???

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

СПАСИБО!

альтернативный текст http://seethreblog.com/images/devel.png

Это было полезно?

Решение

Это очень типично для Drupal:проблемы с разрешениями.Хотя я осознаю, что, вероятно, не смогу дать правильный ответ, может быть, по крайней мере, я вызову в вас какую-то революционную идею, которая поможет вам решить проблему.

Хотя доступ к узлу является стандартным разрешением, которое должно быть включено, существуют и другие, которые могут ограничивать пользователей.У вас включена бесплатная связь?Если да, убедитесь, что доступ по фрилинку также включен.Возможно, вы захотите убедиться, что модули контроля доступа (ACL и те, которые на него полагаются, такие как Forum Access) не мешают.Кроме того, контроль доступа к таксономии может быть болезненным:У меня возникли проблемы с Taxonomy Access Control Lite (tac_lite).Попробуйте отключить его, если он у вас есть.

Прошу прощения, что не могу предложить ничего более конкретного, но Drupal именно такой.Решение проблем с разрешениями редко требует взлома кода.

Другие советы

Через Друпал: http://drupal.org/node/64114

Этот сделал это для меня:«Вы пробовали восстановить разрешения?Перейдите в admin/content/node-settings и нажмите «Перестроить разрешения».

У меня была точно такая же проблема после обновления с 6.14 до 6.15.Пробовал только на двух разных локальных системах OSX, поэтому был заинтригован обнаружением проблем, связанных с вашим сервером...связано ли это с версией PHP - я использую PHP5.2 во всех установках.

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

С момента перехода на 6.15 у меня были проблемы с разрешениями слева и справа.Сайт не был на 100% отлажен в версии 6.14, поэтому я не могу логически сказать, что это определенно вина версии 6.15, но моя интуиция может и говорит это.

У меня есть роль, которую я называю контент-менеджером, которая имеет все разрешения CRUD (создание, чтение, обновление, удаление) для всех типов контента.

Чтобы позволить системному администратору (пользователь №1) редактировать истории, мне пришлось предоставить ему эту роль.Прямо сейчас у меня возникли проблемы с разрешением этой роли редактировать истории.Пользователь с этой назначенной ролью получает ошибки «отказано в доступе».

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top