On Sunday, May 31, 2015 at 12:19:22 AM UTC-4, Aikido Guy wrote: > > On Friday, May 29, 2015 at 2:57:41 PM UTC-4, RjOllos wrote: >> >> On Friday, May 29, 2015 at 2:39:33 PM UTC-4, Aikido Guy wrote: >>> >>> *I am using Trac 1.0.2 and would like to create a restricted authenticated >>> shared user.* >>> >>> *For this goal, I have created a user with a password that is managed by >>> htpasswd in Apache.* >>> >>> *Then I created a user in Trac with only WIKI_VIEW.* >>> >>> *I can then share this restricted authenticated username+password to more >>> than one (unknown) person.* >>> >>> >>> *However, this user now has a "preferences" in the metanav that they (in >>> theory only?) are able to set.* >>> >>> *How can I disable "preferences" for this shared user that should only have >>> WIKI_VIEW and does not need to set email preferences?* >>> >>> >>> *I understand that the following might disable preferences for all users, >>> not just this one user.* >>> >>> [metanav] >>>> preferences = disabled >>> >>> >>> *Is it possible to disable "preferences" for one user only?* >>> >>> >>> *Any help would be very much appreciated!* >>> >>> >>> *Kindly,* >>> >>> *Aikido Guy* >>> >>> >> There are no permission checks prior to rendering the panels in the >> preferences module. >> >> As far as I can see, your only option would be to write a plugin >> implementing IRequestFilter. >> >> http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.web.api.IRequestFilter >> >> The simplest would be to just reject edits to the preferences pages by >> the "specialuser". The following untested code in >> IRequestFilter.post_process_request might do the job: >> >> if req.authname = 'specialuser' and req.path_info.startswith('/prefs') >> and req.method == 'POST': >> raise PermissionError("You can't edit!") >> >> If you want to take it even further, you could probably remove the >> Preferences contextual navigation item in post_process_request or even >> prevent the user from navigating to the /prefs pages by typing in the URL. >> > > Thank you for the information and tips! I will look into implementing > something in the next month or so. > > Kindly! >
I'm now trying to implement this. As a first step I am implementing a plugin that does nothing. When looking at the log files, I don't see any error message nor any messages at all related to my plugin, so it seems that the plugin is not loaded? However, I have created a macro that is successfully loaded from the same directory and I get a message in the trac.log to that effect. My new plugin has the same permissions as the old macro. I've also checked the trac.ini file and enabled the component. Some questions: 1 - What should be the name to put in the [components] section of the trac.ini file for class A(Component) implements(IRequestFilter)? 2 - Should A have a special form? I've tried FooPlugin, FooModule, FooMacro. All to no avail. Help sorting this out would be very much appreciated! Kindly, Aikido Guy -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
