Separate URL and settings permissions

This is something I would also like to see.

I also would like to see this.

I propose adding a new permission for the Settings page. Patch to follow...

Patch is attached...

+1

Updating title

Updating the beginning hash in the patch from #3 and setting Needs Review in an attempt to trigger the tester.

I'll note the patch does not include the /404 request. I agree that this is a separate request for scope control.

Actually, there is a potential security issue for anyone who applies the patch in #3/#6 prior to it being committed to the module.

It would be better to redo this code such that the less-dangerous permission were the added one. That way, if we suddenly had to lose the patch due to a security upgrade to the Redirect module, only the more-dangerous setting would remain in effect.

That is:

Current system: Only Admin has permission 'administer redirects'

With #3/#6 patch:
Admin and trusted non-admins get assigned permission 'administer redirects'
Admin gets assigned new permission 'administer redirect settings'

If we have to back out the patch for a security update to the Redirect module, we are left with:
Admin and trusted non-admins have permission 'administer redirects', which includes access to settings. (security issue)

With proposed patch (not posted yet):
Admin continues to have permission 'administer redirects'
Admin and trusted non-admins get assigned permission 'add edit or delete redirects'

If we have to back out the patch for a security update to the Redirect module, we are left with: Only Admin has permission 'administer redirects', which includes acces to settings. (no security issue)

I realize that's more coding, which I don't have time to do now or I'd post an updated patch, but it's much more secure. In addition, the scope of both permissions would be more accurate.

The separation of these permissions is something that ultimately needs to be done. Users should be able to add redirects and admins should be able to administer the roles without the permissions overlap.

The current permissions are set to "administer redirects". Ultimately these permissions should only be used for the settings page. I agree with above that it is an unintended security flaw by doing it this way. One could always supply a hook_update() function to convert the old permission to the newly created one "add/edit/delete redirections". This seems to make the most sense to me at least. Now if I could just find the time to write a patch...

Until this issue will be fixed, this snippet may be useful for someone:

/**
 * Implements hook_menu_alter()
 */
function your_module_menu_alter(&$items) {
  // This is required until issue https://www.drupal.org/node/2078423
  // in Redirect module will be fixed
  $items['admin/config/search/redirect/settings']['access callback'] = '_your_module_redirect_settings_access_callback';
}

function _your_module_redirect_settings_access_callback(){
  global $user;

  // Forbid access for roles different than administrator
  return (in_array('administrator', array_values($user->roles))) ? TRUE : FALSE;
}

Re-roll of #6 against 1.0-rc4.

Regarding the perceived security issue, this presumes that:

• The module is eligible for security coverage (it isn't, because there still isn't a stable release 6 years after this concern was brought up).
• A security release was put out that causes an incompatibility with the patch. If this happens, it's 4 lines of very low-complexity code (menu and permission declarations) to re-roll.

Applying a patch is an inherently "use at your own risk" choice, though it's good to make people aware of a gotcha if they choose to revert the patch.

Closing this as Outdated as Drupal 7 is EOL.