I have created several pages in my drupal website and set permissions to each of the page depending upon the roles I have.
The problem is if I know the URL, I can access that page even though I am not a registered and authorized user.
This will be a problem if some random person/hacker plays around with the URLs and comes across a page that is supposed to be viewed by an authorized user.
I am new to Drupal and any help is appreciated.
If you correctly set the permissions it will restrict access based on roles regardless if they know the URL. Are you sure that when you are testing it you are actually signed into or using a role that doesn't have access to that page?
Drupal lets you set permissions for who can Create, Edit and Delete content types. You need a contributed module for setting who can 'View' permissions of individual pages/nodes.
Download Content Access from https://drupal.org/project/content_acces. After you install it and configure the default values for the content type, you will need to click the content access tab after you create the page.
'Taxonomy Access Control Lite' is very light and more user-friendly; permissions are set within the edit view (normal fields), however, it takes some effort to understand how it works and to set it up.
See a comprehensive list of node access modules at https://drupal.org/node/270000
Tip: Don't use more than one module for node access permissions.
I'm getting a redirect loop on a Drupal 7 install. Whenever a non-admin user logs in, the site will enter a redirect loop on the user profile URL; for example, http://example.com/?q=user/testuser.
This URL is accessible with no issues by the superuser account, and attempting to access this URL while logged out returns a 403 Access Denied as expected.
When logged in as a non-admin user, attempting to access any URL at all will redirect to the user profile page, which will then redirect onto itself, causing the redirect loop to start anew.
I have found that if I give a specific user the "administrator" role, the redirect loop will cease for that user, and the page will no longer try to redirect to user/%username on login.
I have also found that if I give users the "administer users" permission that the redirect loop will cease, but will still redirect the user to user/%username on login.
Obviously neither of these solutions are possible as giving regular users administrator roles or the ability to administer users is a huge security risk.
Does anyone know of a fix for this, or a way to get around this with an override related to user role?
Installed modules: Block, Color, Comment, Contextual links, Dashboard, Database logging, Field, Field SQL storage, Field UI, File, Filter, Help, Image, List, Menu, Node, Number, Options, Overlay, Path, RDF, Search, Shortcut, System, Taxonomy, Text, Toolbar, Update manager, User, Chaos tools (7.x-1.0-alpha4), Page manager, Devel, Theme Developer, Fieldgroup, IMCE, Pathauto, Token, Taxonomy Menu, IMCE Wysiwyg API bridge, Wysiwyg, Webform, and several custom modules which i) provide blocks 2) provide custom pages and 3) modify the default search behaviour (splits search results by node type). None of my custom modules ever interface with the user management system, permissions system or use any of the functions provided by the user module.
I had an identical problem... spurred on by the fact I wasn't the only one faced with this issue I dug around a bit more. It was your update that gave it away - the Custom Theme.
I'm sure this could be caused by lots of different factors, but in my case and potentially yours, it was my template.php that was at fault.
I was using a custom MYTHEME_preprocess_page() to make some custom variables available in my templates. One of the variables was obviously a bit funky because when i removed it the problem disappeared. Turns out it was some left over code from when I was trying to get the user registration form into the page. It never worked and I forgot to remove it!
Hope this helps someone out there get back on track.
I haven't solution, but you can investigate in next way:
1. Goto http://SITE/admin/config/development/devel for devel module settings.
2. Check "Display redirection page" and save settings.
3. Goto http://SITE/admin/people/permissions
4. Check "Access developer information" for anon and other roles, and save.
5. Try login, it should stop on redirection pages and show where it try to redirect, so you can detect, what modules call looping.
I also had a problem with redirect-loops randomly occurring for non-admin users. Looking at /admin/reports/dblog revealed a permission problem with several nodes. I fixed it by flushing the node permissions (see /admin/reports/status/rebuild). Now everything is fine again.
Same problem for me, after hours and hours of debug and forum/blog navigation I finally found what was going on my site...
If you force login block in all pages, even if user is already logged in, only admin can navigate pages.
This is one of the possibles causes, I hope can help someone!
I had the same problem because i was loading the login form even when the user was logged in. fix it by not asking for the form only if the user is anonymous.
from https://www.drupal.org/node/1793230
Run these SQL queries in your MySQL database. If you have drush installed, you can just "drush sqlc" from your settings directory to get into a MySQL command line. Otherwise you can use PHPMyAdmin, MySQL workbench, or some other client tool to connect and run these:
Show records to be deleted:
SELECT r.rid, r.language, r.source, r.redirect FROM redirect r INNER JOIN url_alias u ON r.source = u.alias AND r.redirect = u.source AND r.language = u.language;
Then, to delete redirects shown in above query - try going to the pages shown in the row. Chances are you will get a redirect loop. Then, try again after backing up db and running the delete below. You have to turn off safe mode in MYSQL Workbench to run it, so BACKUP:
DELETE r FROM redirect r INNER JOIN url_alias u ON r.source = u.alias AND r.redirect = u.source AND r.language = u.language;
Fixed my problem, and found other pages that had loops which I didn't even realize!
My Drupal / ubercart install has a bizarre issue. Anonymous users can access an edit page /node/44/edit for s SINGLE node only - an ubercart product. I have created a new version of the node, which does not have the issue. The tabs (view / edit) are also available on the product page to anonymous users. The issue became clear when the page was edited by a spam bot.
Is there any way I can output the decision making process which Drupal makes to the screen? For example can I output the variables to the screen which Drupal uses to make the decision about whether the user has access to a given URL or not?
Thanks in advance.
There may be a better way, but to start, you could create a custom module that implements hook_menu_alter, then dump the contents of the $items array, to see the access callback associated with /node/44/edit or /node/%/edit.
One thing to try would be to "rebuild node permissions" You do this from the admin/content/node-settings page. It might be as simple as the permissions being jacked up, which is rare but does happen sometimes.
I have Workflow Permissions configured but they don't seem to be working properly. I'm trying to allow the author to View posts in the Paid state but not edit. Here is the permission matrix for this: http://screencast.com/t/dqqKwc1kcd
The result of this configuration allows the author to both View and Edit.
If I uncheck View, the author can no longer view or edit. It seems to be half working. Any tips?
I would try unchecking the "edit own" permission for that content type in the place where all the drupal permissions are.
After permissions changes, rebuild your site permissions, at: admin/reports/status/rebuild
Is there a way to have a content type that is only viewable to admins AND the person who created it, including comments? I feel like I know the answer to this but its escaping me.
Try the Nodeaccess module. Some more details about this module (from its project page):
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
If the content type is defined by your own module, you can use hook_access to do this.
If the content type is defined by CCK or another module, things are a bit trickier. You can install a patch that adds an access op to hook_nodeapi, but unfortunately that's a hack to the core Drupal code, with all the potential upgrade pitfalls that ensue.