Please login or register to participate.
Blog Post

Bug found and fixed -

.

Hi!
We are engaging another cyn.in space at the academy of fine arts in Vienna. We are using the downloaded version 3.1.1. Now when we set an internal link to an item that is only project-visible we encountered an "Insufficient Privileges" Error. I looked into the error logs and found the reason: "Unauthorized: You are not allowed to access 'title' in this contex". I looked into the code and found that in the template "links_macro.pt" the property "item/title" is being used. I was able to fix the error by using the property "item/Title" - which is accessible on a catalog object. Here's the patch, i hope you can apply it for future versions!

Index: src/ubify.cyninv2theme/ubify/cyninv2theme/skins/ubify_cyninv2theme_custom_templates/links_macro.pt
===================================================================
--- src/ubify.cyninv2theme/ubify/cyninv2theme/skins/ubify_cyninv2theme_custom_templates/links_macro.pt	
+++ src/ubify.cyninv2theme/ubify/cyninv2theme/skins/ubify_cyninv2theme_custom_templates/links_macro.pt	
@@ -101,7 +101,7 @@
                            tal:attributes="href item_url;class string:relateditemlink"
                            >
                             <img tal:attributes="src item/icon" border="0"/>
-                            <span tal:content="item/title" />
+                            <span tal:content="item/Title" />
                           </a></li>
                     </ul>
                 </div>

Now the "Linked Content" displays right and the security issue is solved. We are very happy with cyn.in here and once more want to express our kind regards to the cynapse team!

Georg Gogo. BERNHARD

Comments (9)
dhiraj Apr 30, 2010 10:38 AM
Thanks Georg!
But this error doesn't occur normally, right!? I just got someone to test it here and we are unable to reproduce the problem in all states of link objects in a Space, with various permissions. Insufficient privileges is only happening, correctly, when the user doesn't have view access.

This is weird -> normally, in Cyn.in, when someone can navigate to the full item view - they have at least view access on the link object. When they do, the object is loaded, and the title attribute *will* normally work in this case. So... is there something different in your particular case? Or are you not talking about the full item view, and some other screen?

I've added an issue for this, and have already targeted it for next release, in either case we'll accept the patch into trunk or reject it. http://odn.cynapse.com/issues/1341

One thing you can try: go to portal_workflow in ZMI and click the link at the bottom which repairs all the workflow on all objects in the site and see if it fixes the problem?
gogobd Apr 30, 2010 01:21 PM
Well, here our users don't have the "Member" role per default, this could be the difference; Using "Title" should be the safer option. Thank you for checking - clicking the workflow repair made no difference...
dhiraj Apr 30, 2010 01:52 PM
I see! So you're not giving normal users Member role. Hmm.... yes, possibly that can cause this problems, and yes, portal_workflow wouldn't fix that, obviously.

Any particular reason for not giving Member role? Is it advisable? There could be more problems, right? I mean, without the Member role, they're not getting the "Logged in users" local role assigned to them, basically. Could cause more problems. Usually giving Member role does not cause any harm (from a security perspective) AFAIK, but without it, your users are almost like anonymous users, except that they're logged in, so they're not even anonymous! :)
gogobd May 03, 2010 07:27 AM
Well, we do have students and employees - and only some of the users who can actually log in should be able to see certain spaces at all. So we considered not to give everyone the "Member" role just by default. It would be great if we could just give certain users them "Member" role in one space, but I don't think that the Zope/Plone infrastructure would allow for that. It would also fix a problem that users can't subscribe content via email and other small issues.
Do you by chance have an idea if we could engage the "Member" role per space?
dhiraj May 03, 2010 09:55 AM
I'm not sure right now (too early in the day, not enough coffee!) but I *think* I remember that there's a difference between the way Plone and Cyn.in treat the base Member role.

In Cyn.in, using Member on all logged in people is recommended, as long as you only have Cyn.in default products - with default Cyn.in products, we have taken care of the workflows such that Members <-> Logged in Users mapping will always work.

If you want to deny access to all default logged in users to a Space, and only allow specific users access to the Space, do the following:
1. On the Space, go to the Sharing tab and remove inherit permissions from parent, and save.
2. Doing this should turn off all checkboxes on Logged in users. If not, turn them off and save.
3. Turn on Can View for only the users/groups who should see the Space and contents (but not add/edit contents).
4. Turn on Can Add for only the users/groups who should see and be able to add/edit contents inside the Space (but not edit Space permissions). Can Add implicitly means Can View.
5. Turn on Can Edit for only the users/groups who should be able to edit the Space and assign Sharing permissions. Can Edit *does not* mean implicit Can Add, give this separately.

People who don't have Can View on a Space will not see it, and not even know about it. Direct navigation by url will give them Insufficient Privileges or even 404 depending on your SSO - like on Cynapse Community you get a 404 instead of Insufficient Privileges page, if you don't have access.

Refer to this for more info on permission mapping: http://www.cynapse.com/comm[…]onymous-access#section-41or feel free to ask for more particular details if you have doubts. :)
gogobd May 03, 2010 11:10 AM
Dear dhiraj!
Thank you very much for that suggestion, I will try that out. We clicked away the "inherit" checkbox anyways. Maybe we would be safe by just adding the "Member" role to every logged in user. Now we only make them "Authenticated"... I'll let you know if that procedure is working for our usecase!
gogobd May 04, 2010 12:31 PM
Okay, now we give the "Member" role to all logged in users and it looks very good - for restricted spaces we proceed as you suggested and it works great. Thank you for your support! We really appreciate that the cynapse team is so cooperative and agile! Great! Thank you!
revelasquez Sep 05, 2011 07:42 PM
I have the same problem, sometimes when a member user try to add a web link or other resource, show him or her the message: "Insufficient privileges". I did the step described in the conversation but i couldn't resolve the problem. Each user have to try two times to add a resource, what could i do to resolve this problem?
gsiak Oct 04, 2013 12:46 PM
The problem behind ist NOT the member role!
Script links_macro causes two major issues in my 3.2.2 installation:
1. insuffient privileges as described above and
2. acscii code error in script computeReferencedItems called by links_macro when item names cotaining non-ascii character e.g. German Umlaute.
 
Loading