Opened 3 years ago

Closed 16 months ago

#12630 closed defect (fixed)

Change in #7594 disables editing a blog post by the author

Reported by: t.riedel@… Owned by: Ryan J Ollos
Priority: normal Component: FullBlogPlugin
Severity: blocker Keywords:
Cc: massimo.b@… Trac Release: 1.0


The change made in r14773 (#7594) causes wrong permission checking in plug-in FullBlogPlugin.


  • Updated to trac v1.0.9
  • Updated FullBlogPlugin to v0.1.5
  • A logged in user foo with Foo Test as Full name in the preferences.

If the user now (now in the meaning of: after update to v0.1.5) adds a new blog post his full name (Foo Test) is set as value for author instead the user's id (foo).

The user is no more able to edit his post, since the database table now contains the full name (Foo Test) as author and not the user's id (foo). Permission checks fail.

I suggest:

  • When adding a new post, the field author must contain the user id
    • if possible I would like to have an option to disable changing the value of this field when adding a new post, otherwise one can post as a different user
  • The column author in the database scheme must always contain a user id
  • With the user id of the database it is easy to show the user's full name on all pages if one is set

Attachments (1)

t12630.diff (5.7 KB) - added by Ryan J Ollos 16 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by osimons

Right. This problem arises with the BLOG_MODIFY_OWN permission check. Which of course is the same problem you get if you create/edit posts in a different name than your own. BLOG_MODIFY_ALL permission can of course set and edit any posts.

First, the suggestions in the ticket descriptions are good ideas but not so easy to complete. Trac does not store users as such, and doing lookup in the sessions of all users referenced in author categorization will be painful. A lot of code and extra processing. And username may of course be 'anonymous' that cannot be looked up later.

Also, the basic idea of author is really just a dimension of categorization. Inside a typical project it is no different than letting anyone post to a named category that by use should be reserved for a select few. This is not a heavy-duty blogging system, and in the spirit of Trac I would much rather have freedom and flexibility (permissions allowing).

I'm tempted to just require BLOG_MODIFY_ALL permission to set/edit the author field through web:

  • tracfullblog/templates/fullblog_edit.html

    a b  
    1818    <py:with vars="is_create = not blog_edit.version;
    1919                   can_create = 'BLOG_CREATE' in perm('blog');
    2020                   is_edit = bool(blog_edit.version);
    21                    can_edit = 'BLOG_MODIFY_ALL' in perm(blog_edit.resource) or defined(
     21                   can_modify_all = 'BLOG_MODIFY_ALL' in perm(blog_edit.resource);
     22                   can_edit = can_modify_all or defined(
    2223                        'blog_orig_author') or (
    2324               and 'BLOG_MODIFY_OWN' in perm(blog_edit.resource));
    2425                   is_allowed = (is_create and can_create) or (is_edit and can_edit);
    100101                <input id="blog-author" type="text"
    101102                      name="author" size="40"
    102103                      value="${(defined('blog_edit') and
    103                                or (req.session.get('name') or req.authname)}" />
     104                              or (can_modify_all and req.session.get('name')
     105                                  or req.authname)}"
     106                      disabled="${not can_modify_all and 'disabled' or None}"/>
    104107              </div>
    105108              <div class="field">
    106109                <label for="blog-categories">Categories (space separated):</label><br />

Would that be OK?

comment:2 Changed 3 years ago by t.riedel@…

Sorry, that my reply took so long, I didn't get an information that there was a comment left here. Or I didn'et see it.

However, back to the ticket:

At first some background to the usage environment:

  • A trac instance with LDAP authentication
    -> User ids are fixed. Full names not necessarily (marriage, ...)
  • TracFullBlogPlugin used as a project blog, where blog posts are required to be modified only by its author.

Yes, it is correct that a user can create a post as a different user, but that is IMHO another request to extend the plugin to disable this (maybe via an option/setting). Currently we "live" with this and tell the users to not modify the author field.

To be honest: I do not really understand (I'm not a python !developer) what your proposed changes will change and if it fits our needs. As I see you add the attribute 'disabled' to the 'input'-tag with a value depending on some variables. This sets whether author can be changed or not. But does this change the value put into the author field?

Another suggestion from me:

Maybe it is possible without too much coding to add an option / setting in the admin section what kind of information is used as the default author for a blog post when it is created? Maybe three choices:

  1. Empty
  2. UserId of current user's session (which is what we need)
  3. Full name (it's OK, if this is the default setting to keep compatibility)

And in addition (if this is not too much work) an option whether changing the author field on creation/editing is allowed.

comment:3 Changed 22 months ago by Ryan J Ollos

Additional issues with r14773 noted in comment:11:ticket:7594. I agree with points made in comment:description, and proposed some solutions in comment:11:ticket:7594. Eventually I'll probably generate a patch as this is causing problems on

comment:4 Changed 20 months ago by Ryan J Ollos

#13212 closed as a duplicate.

comment:5 Changed 20 months ago by Massimo

Cc: massimo.b@… added

comment:6 Changed 16 months ago by Ryan J Ollos

Owner: changed from osimons to Ryan J Ollos
Status: newaccepted

comment:7 Changed 16 months ago by Ryan J Ollos

I'm preparing a patch. I tried testing with Trac 0.11 per preference of osimons. r14886 is not compatible with Trac 0.11:

TemplateNotFound: Template "attach_file_form.html" not found

I absolutely do not care about Trac 0.11. The last commit to the Trac 0.11-stable branch was 7 years ago.

Since the fullblog branch is not compatible with Trac 0.11, I'll test with Trac 0.12. If the fullblog branch is made compatible with Trac 0.11 and that's needed to accept my patch, then I'll make my patch compatible with Trac 0.11.

Changed 16 months ago by Ryan J Ollos

Attachment: t12630.diff added

comment:8 Changed 16 months ago by Ryan J Ollos

Proposed changes in t12630.diff:

  • Anonymous users with session info will have a name like User One <>, as requested in #7594.
  • The authname is always stored in the database for authenticated users.
  • Full names will be rendered with Trac 1.2 and later.
  • User datetime format preferences are respected in Trac 1.0 and later.

comment:9 Changed 16 months ago by Ryan J Ollos

Resolution: fixed
Status: acceptedclosed

In 16824:

TracFullBlogPlugin Store authname in database

The fullname (Trac 1.0+) and user datetime preferences
(Trac 1.2+) will be rendered. Anonymous users will have
a username comprised of their session name and email.

Fixes #12630, Refs #7594.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.