Security

Disables the user interface for creating and assigning roles and permissions.

Secure Permissions is an advanced security module for Drupal 7. It disables the Roles and Permissions editing screens and lets all user roles and permissions be handled through code. This adds an extra layer of security, as the site's permission can no longer be misconfigured accidentally.

This module was inspired the security paradigm of the Plone platform. See, in particular, 'Problem A2: Broken Access Control' in the Plone documentation.

Notes

This module was written in Drupal 7 and could use a backport. A backport would need to leverage the Permissions API module, which is native in Drupal 7.

Security Review automates checking many of the configuration errors that lead to an insecure Drupal site and looks for existing vulnerabilities and attack attempts.

This module allows for first user (uid 1) to create a login name different from username. It can be useful if site admin does not want to reveal login name of the first user for whatever reason. It should be noted that hiding admin's login name does not necessarily add to better security, and having secure password is more important.

User One also lets site admin specify list of allowed IP addresses from which admin account can log in.

Features added for alpha 4 release:
View and edit of user one account is controlled.
Deletion of user one account is blocked for every user including user one itself.

The project has been developed by Urban Insight.

Vocabulary Access is similar to Taxonomy Access Control and Taxonomy Access Control Lite, but it makes possible to control node access based on vocabularies. You can grant permissions to nodes by roles and individual users with using three simple built-in (view, update, delete) scheme. These schemes contain all the necessary permissions to the mentioned operations. After installation all permissions are denied by default, see the module settings page at admin/user/vocabulary_access to configure.

Besides nodes, you can control access to taxonomy operations for each vocabulary. You can grant permission to add, edit and delete vocabulary and/or terms in the given vocabulary. Access to administer taxonomy is needed to make these settings work, otherwise the user can do nothing at all.

If you have something to share (bug, feature request, etc) feel free to do so, all feedback welcomed!

If your talking about very very very fast file transfer then here is the destiny.

Why xsend module is made for?

xsend is a simple module to help you to speed up your private file transfers. Normally Drupal private file transfer is quite troublesome and not secure if the files folder is located at public_html. This module will also help protect your files from unauthorized access.

Why you need this?

• If you're still using Drupal public file transfer you're not secure at all. Every one can get your files.
• If you're using Drupal private file transfer, you're secure. But file transfer to the client is very slow.
• Fast secure file transfer can only be achieved from the xsend.

How to migrate to xsend?

• If you're using a standard Drupal installation then follow the instructions in the INSTALL file.
• If you're currently using private file transfer correctly, then you can still use this INSTALL guide, but make sure keep empty, the path to Drupal installation directory settings.

What is mod_xsendfile

mod_xsendfile is a small Apache2 module that processes X-SENDFILE headers registered by the original output handler.

This module has two pieces - Update Reporting (UR) and Update Monitor (UM)
The pair of modules will work together to provide a centralized monitoring system of update status data across many sites.
Both modules are dependent on the core update and contributed views modules. And potentially cvs_deploy if you use CVS to check out your modules.

Update Reporting:
On cron, UR will capture update data and send via XML-RPC to a centralized monitoring site. Other monitoring data like server status, platform information, or other monitoring data will likely be added as this project matures.

Update Monitor:
UM will be enabled on a centralized monitoring site. It will have an XML-RPC server listening for reports from sites using UR module. The incoming update status data will be stored in the cache_update table. There will be a new node type "site" which will hold the monitored sites meta data (domain, IP, administrators info, ...). A view of the monitored sites will be provided. From there a link to the monitored site node will show the site meta data as well as the update status of that site.