Drupal problema permisos de usuario anónimo

Question

He estado devanando mi cerebro sobre cómo resolver este problema por horas ahora, y sé que no soy el primero en encontrarse con él.

Tengo problemas para conceder acceso a usuarios anónimos al nodo de contenido en Drupal 6.15. He intentado todo, incluso las plantillas a MySQL, comprobación y doble control de permisos cada ajuste disponible (sí, he permitido que "el contenido de Acceso"), la reconstrucción de los permisos, y borrar la memoria caché. Tengo módulos personalizados con discapacidad en la esperanza de la limpieza de un conflicto, pero aún ninguna suerte. Los usuarios anónimos reciben la página "Acceso denegado" en todas partes, pero en una página de calendario personalizado Ver.

He tratado de estas consultas, pero no son más que duplicados de lo que ya existe:

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);

Mi única luz de esperanza: "Permisos de acceso de usuario" del módulo Devel pantalla de hecho muestra que el usuario: Anónimo no puede ver el contenido (ver imagen). Plantea una pregunta desconcertante: ¿cómo es que "Todos los usuarios pueden ver todos los nodos", mientras que el usuario: Anónimo tiene al mismo tiempo "NO: acceso a contenido" ???

Esto me está volviendo loco. Si alguien me puede alertar en cuanto a lo que estoy haciendo mal, voy a saltar arriba y abajo en el entusiasmo, y comprar una cerveza si se encuentra en Seattle.

GRACIAS!

texto alternativo http://seethreeblog.com/images/devel.png

Answer 1

Esto es muy típico de Drupal: problemas de permisos. Aunque soy consciente de que probablemente sea incapaz de ofrecer la respuesta correcta, tal vez por lo menos voy a accionar una cierta idea revolucionaria en ti que le ayudará a resolver el problema.

Si bien el acceso es un nodo de permisos estándar que debe estar en, hay otros que pudieran restringir los usuarios. ¿Tiene freelinking en? Si es así, comprobar que el acceso freelinking también está encendido. Es posible que desee asegurarse de que los módulos de control de acceso (ACL y los que dependen de ella, como el Foro de Acceso) no se interpongan en el camino. Además, el control de acceso taxonomía puede ser un dolor: he tenido problemas con la Taxonomía de control de acceso Lite (tac_lite). Intente desactivarla también si lo tienes.

Me disculpo por no ser capaz de ofrecer algo más específico que esto, pero Drupal es exactamente igual. Solución de problemas de permisos rara vez requiere hackear el código.

Answer 2

A través de Drupal: http://drupal.org/node/64114

Éste lo hizo por mí: '¿Usted intentó reconstruir los permisos? Ir a / content / node-configuración de administrador y haga clic en "Reconstruir permisos". "

Answer 3

He tenido exactamente el mismo problema, ya que la actualización de 6.14 a 6.15. Tratado únicamente en los sistemas locales OSX 2 de diferencia, tan intrigado a encontrar sus problemas relacionados con el servidor ... es la versión PHP relaciona -. Estoy corriendo PHP5.2 en todas las instalaciones

tabla de permisos reconstruido y mirado el permiso del usuario en cada concebible, pero los usuarios reciben la misma anon 'Por favor, regístrate para continuar'. Parece que vale la pena publicar un problema en la cola de emisión de Drupal.

Answer 4

Desde que fui a 6,15 que he tenido problemas con los permisos de izquierda y derecha. El sitio fue depurando no al 100% en 6,14 así que no puedo decir, lógicamente, que sin duda era culpa de 6,15, pero mis intuiciones pueden y decirlo.

tengo un papel que llamo gestor de contenidos que tiene todo el CRUD (crear, leer, actualizar, eliminar) los permisos en todos los tipos de contenido.

Para permitir que el administrador del sistema (usuario # 1) editar historias que tenía que darle ese papel. En este momento estoy teniendo problemas dejando que el papel editar historias. Un usuario con ese papel asignado pone 'acceso denegado' errores.

El único otro módulo Tengo que manipula los permisos se 'papel delegación' de modo que ciertos usuarios finales pueden tener acceso a la asignación de funciones, pero no editar papeles o para asignar permisos a los roles. Todavía tengo que perseguir a esto y la posibilidad de una tabla de permiso corrupto. Pero la posibilidad de que 6,15 es todavía existe el culpable.