Personal tools
You are here: Home Documentation How-tos Debugging Unauthorized / Insufficient Privileges
Support

Get Help

Join our chat rooms or support forums if you have more specific questions.

Plone Training
Learn how to design, build, and deploy a website in Plone through one of the numerous Plone training sessions around the world.
Find Plone training…
 
Document Actions

Debugging Unauthorized / Insufficient Privileges

This How-to applies to: Any version.
This How-to is intended for: Developers

One of the most common errors you will get as a Plone developer is the "Insufficient Privileges" message. This message does not tell you exactly what went wrong for security reasons, but there are ways to expose this using VerboseSecurity.

If you just want to see error messages instead of "Insufficient Privileges," then start with step #3. However, to get meaningful error messages you will need to install/enable Shane Hathaway's VerboseSecurity product.

For Zope 2.7

  1. Install VerboseSecurity

    Download VerboseSecurity - it provides more meaningful error messages for Unauthorized errors. Specifically, it tells you where your request failed, what roles you have, and what roles you need to perform your request.

  2. Restart Zope

    In the ZMI check Control_Panel/Products for VerboseSecurity.

    VerboseSecurity complains to the event log if it cannot install its security policy, so check log/event.log for messages.

    Also see the page on VS in the ZopeWiki.

  3. Edit cookie_authentication

    In your Plone site go to cookie_authentication and clear out the Auto-login page ID field. Press Save Changes.

    The idea is that a security violation should no longer redirect to the login page, but display the browser's basic auth dialog.

For Zope 2.8+

  1. Enable VerboseSecurity

    VerboseSecurity is built in to Zope 2.8+, but you will need to enable it in etc/zope.conf. In zope.conf, search for verbose-security and set verbose-security on. Search for security-policy-implementation and set security-policy-implementation python.

  2. Restart Zope

    VerboseSecurity complains to the event log if it cannot install its security policy, so check log/event.log for messages.

    Also see the page on VS in the ZopeWiki.

  3. Edit cookie_authentication

    In your Plone site go to cookie_authentication and clear out the Failed authorization page ID field. Press Save Changes.

    The idea is that a security violation should no longer redirect to the login page, but display the browser's basic auth dialog.

For all versions of Zope

  1. Find a browser that fails well

    Mac OS X

    • Firefox. After you entered the login information once, you can press Cancel at the second pop-up and see the error message.
    • Opera works the same as Firefox.
    • IE 5.2 shows error message after first unsuccessful login attempt.
    • Safari and Camino can NOT be used for this!

    Windows

    • IE 5.5 & 6 require you to enter the login info 3 times before showing the error message.
    • Firefox and Opera should work like on the Mac.
  2. Configure the error_log

    Plone's error log ignores Unauthorized errors by default. If you want to log these errors, then simply browse to the error_log (either in ZMI or in Plone Setup) and remove Unauthorized from the list of "Ignored exception types." Click Save and you're set.

  3. Access the problem area

    Using a browser, access the part of your site causing Unauthorized errors. The browser should pop up a login dialog. Enter the credentials of the offending user at least once. This depends on the browser used, see 4.

    You should now see a Plone Site error, where the error value contains a detailed textual explanation of why access was denied.

  4. Don't do this on a live system!

    If you can avoid it. Production Zopes should not run in debug mode, and not have the VerboseSecurity product installed.

Additional notes

There are cases where these error messages do not show up in the page itself, and you still get "Insufficient privileges". The verbose errors will be logged in the error.log file in your Plone instance. This is relatively uncommon, though.

The security framework generates the verbose information. If something raises Unauthorized exceptions directly, there will be no verbose information. Example for this is the at_isEditable.py script, which raises Unauthorized exceptions when there are zero editable fields in an Archetypes item. In that case you won't know which permissions you'd need.

And hey, if you get a simple "Username and password are not correct." error, it may be because the user simply does not have the correct View permissions on the object you are trying to access :-) There may not be a deeper problem :-) Check and double check.

by Stefan H. Holek last modified July 30, 2007 - 13:22
Contributors: miohtama
All content is copyright Plone Foundation and the individual contributors.

If you're on Plone 2.5 …

Posted by Sean Kelly at December 14, 2006 - 01:54
… and you can't find cookie_authorization, it's because the Plone Pluggable Authentication Service does things differently. So, to get the same effect as clearing the "Auto-login page ID", open up the acl_users object in your PloneSite in the ZMI, open the Contents tab, check the box next to "credential_cookies_auth", and hit Delete.

this is not true!

Posted by Yuri at April 24, 2007 - 10:34
If you do this, you can't login and do nothing!

It's true

Posted by Sean Kelly at April 24, 2007 - 13:17
True: you can't log in; but you will get the verbose security message explaining what the bug is—*which is the entire point*. After you learn what the cause of the security bug is, merely undo the deletion of credential_cookies_auth from the ZMI.

(Hint: use two browsers: one logged in as a manager so you can delete and undo the deletion of credential_cookies_auth, and a second that can trigger the verbose security message.)

Remove Custom Type from Portal Factory

Posted by David Bain at March 22, 2007 - 13:59
Ensure that your custom type is NOT in the factory types. Go to 'ZMI' > 'portal_factory' > 'factory types', uncheck your custom type, if it is checked and 'save'.

explanation:
Portal Factory adds additional and unecessary "machinery", which sometimes interferes with the proper working of verbose security. I found that I did not see useful messages on my custom type when it was listed as a factory type.

This would have saved me 2 to 3 days had I known this earlier.

re Remove Custom Type from Portal Factory

Posted by Dave Marsden at May 22, 2007 - 14:52
You saved me 2-3 days though. Thanks for the tip which worked.

Checklist for Plone 2.5.2/Zope 2.9.6 on Linux

* Uncomment the 2 lines of verbose security declarations in zope.conf (Lines 561,562 in mine)
* Delete "credential_cookies_auth" object from acl_users in your site root (not zope root). This switches the authentication type from cookie to http and is required by verbose security.
* Remove your custom types from portal factory (I found debug totally failed without this step as per pigeonflight's warning)
* Restart zope (I use zopectl fg allowing me to see the exceptions in a terminal window)
* In your 'Site Setup' -> 'Error log' remove the line "Unauthorized" from the "Ignored exception types" box and save (Again, for me this was essential)
* Quit browsers you are logged in on. (This will also apply later if you are moving between testing numerous logins. You switched to http authentication and this requires a browser quit to be reset and change user)
* Start up another browser (or access your site using IP address in another instance/tab of the same browser) to separate your admin authentication from your testing authentication.
* Test, vanquish, celebrate

If you have problems try creating a new test user. Don't forget to give your new user the role you want to test!

(My original users (imported from production site) didn't work after I turned cookie authentication off and I don't know why. I would get a login failed message when accessing protected content/actions rather than returning to an identical, empty, login box which you will see when logging is functioning properly but you don't have the right permissions).

Deleting credentials_cookie_auth did _NOT_ work

Posted by David Hostetler at March 6, 2008 - 06:03
I discovered the following:
- deleting credentials_cookie_auth (as described above) didn't allow me to see the verbose security output. Rather (as one poster indicated) it simply prevented me from logging in _at all_, which in turn made it impossible to trigger the Unauthorized error, since the action that triggers the error requires an authenticated user to be logged in.

- So, instead, I restored credentials_cookie_auth, and merely disabled it's challenge plugins, as follows:

- configure verbose security as described above
- navigate (in the ZMI) to the acl_users in the site root
- select the credentials_cookie_auth
- click on 'Challenge'
- select the two entries in the 'Active Plugins' box and transfer them to the 'Available Plugins' box (effectively disabling them).

Once I'd done that, I was able to still login as a user, and then exercise whatever sequence was generating the Unauthorized errors. The verbose security logging showed up in the error_log, as well as in the console (when running './zopectl fg').

With credentials_cookie_auth completely deleted, I'm not sure how you're supposed to actually test anything, since you can't login as a normal user.

List of common problems?

Posted by Sven Deichmann at February 28, 2008 - 11:25
Facing a concrete problem right now (no... nothing with parking lots... (SCNR)), what about a list of possible causes like former admin user that have been taken the Manager rights? Proxy Roles... stuff not only to find the error, but how to "best-practice-solve" them?

For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by