Module Description
The Content Access module let you content manage access permission in a flexible and transparant way.
It provides two new permissions: view all (allows anyone to view the content) and view own (allows only the content creator to see his/her own content). It also gives access to the existing core permissions edit and delete on the same settings page.
It provides the following modalities:
* Each content type can have its own default content access settings by role.
* Optionally you can enable role based access control settings per content node.
Features:
* It comes with sensible defaults, so if you don't configure anything, everything stays working as before.
* It can work with per content type settings, and per content node settings.
* It optimizes the written content node grants, so that only the necessary grants are written. This is important for the performance of your site.
* The Drupal 7 version comes with a submodule named Content Access Rules Integrations to allow integration with the Rules module. This feature is not available for the Drupal 9 or later version. Instead you may use the following contributed module: ECA Content Access.
* The module implements automated testing to ensure everything stays working correctly.
The module is designed to be simple to use, but can be configured to provide really fine-grained content access permissions.
Security policy This project has not opted into security advisory coverage. All security issues are handled in public, in the project's issue queue.
When a project opts into security coverage, all security issues are handled in a private issue queue (i.e. only accessible by the security team and project's maintainers). If it is not under security coverage, security issues are handled in public, in the project's own issue queue.
To make this project secure has proved to be very complex. To make sure that it protects content access in all possible contexts (published context vs. unpublished, translated vs. untranslated, cached vs. uncached, etc.) Also: Roles and grants may be manipulated by other projects. To be secure, this project needs to detect and respond to all these contexts and changes in a consistent and predictable fashion.
Handling security issues publicly provides more eyeballs, and more diverse testing contexts. It also lets users of the project learn about any security issues first hand, so that they can make more informed decisions about the impact on their configuration. The maintainer thinks that with the current state of the project, this will lead to a more timely resolution of any security issues that are discovered.
I hope that the members of the security team will find the time to lend their expertise to this public process, along with the project's users.
Help wanted Despite being used on more than 40 000 sites, there are still no stable version with security coverage. If you are using this project, and want to see a stable release soon, please help out by testing the current development versions, and report any bugs at the issue queue. Note: Before reporting a bug that you discover in a tagged release, check that it is not already solved in the latest development release.
If you are a developer, you can also help by creating and/or reviewing patches. Issue credit will be given, both for creating useful patches, and for reviewing them. Issue credits show up on your profile page and boosts your standing in the commuity.
Notes
* This project makes use of Drupal's node access API. However, it's recommended to use only one module that does so. If you want or need to use multiple modules that make use of this API, please make sure you have a basic understanding of the API first, e.g. read more on node access here.
Alternatives As an alternative to this module, you may want to explore the following contributed modules:
* Front Page
* Nodeaccess
* Node View Permissions
* Permissions by Term
* Private content
* Taxonomy Access Control Lite
It provides two new permissions: view all (allows anyone to view the content) and view own (allows only the content creator to see his/her own content). It also gives access to the existing core permissions edit and delete on the same settings page.
It provides the following modalities:
* Each content type can have its own default content access settings by role.
* Optionally you can enable role based access control settings per content node.
Features:
* It comes with sensible defaults, so if you don't configure anything, everything stays working as before.
* It can work with per content type settings, and per content node settings.
* It optimizes the written content node grants, so that only the necessary grants are written. This is important for the performance of your site.
* The Drupal 7 version comes with a submodule named Content Access Rules Integrations to allow integration with the Rules module. This feature is not available for the Drupal 9 or later version. Instead you may use the following contributed module: ECA Content Access.
* The module implements automated testing to ensure everything stays working correctly.
The module is designed to be simple to use, but can be configured to provide really fine-grained content access permissions.
Security policy This project has not opted into security advisory coverage. All security issues are handled in public, in the project's issue queue.
When a project opts into security coverage, all security issues are handled in a private issue queue (i.e. only accessible by the security team and project's maintainers). If it is not under security coverage, security issues are handled in public, in the project's own issue queue.
To make this project secure has proved to be very complex. To make sure that it protects content access in all possible contexts (published context vs. unpublished, translated vs. untranslated, cached vs. uncached, etc.) Also: Roles and grants may be manipulated by other projects. To be secure, this project needs to detect and respond to all these contexts and changes in a consistent and predictable fashion.
Handling security issues publicly provides more eyeballs, and more diverse testing contexts. It also lets users of the project learn about any security issues first hand, so that they can make more informed decisions about the impact on their configuration. The maintainer thinks that with the current state of the project, this will lead to a more timely resolution of any security issues that are discovered.
I hope that the members of the security team will find the time to lend their expertise to this public process, along with the project's users.
Help wanted Despite being used on more than 40 000 sites, there are still no stable version with security coverage. If you are using this project, and want to see a stable release soon, please help out by testing the current development versions, and report any bugs at the issue queue. Note: Before reporting a bug that you discover in a tagged release, check that it is not already solved in the latest development release.
If you are a developer, you can also help by creating and/or reviewing patches. Issue credit will be given, both for creating useful patches, and for reviewing them. Issue credits show up on your profile page and boosts your standing in the commuity.
Notes
* This project makes use of Drupal's node access API. However, it's recommended to use only one module that does so. If you want or need to use multiple modules that make use of this API, please make sure you have a basic understanding of the API first, e.g. read more on node access here.
Alternatives As an alternative to this module, you may want to explore the following contributed modules:
* Front Page
* Nodeaccess
* Node View Permissions
* Permissions by Term
* Private content
* Taxonomy Access Control Lite
Module Link
Project Usage
39481
Security Covered
Not Covered By Security Advisory
Version Available
Production
Module Summary
The Content Access module aims to solve the issue of managing access permissions for content in a flexible and transparent way.
Data Name
content_access
OPENAI CHATBOT
OPENAI CHATBOT
