Edgewall Software
Modify

Opened 14 years ago

Last modified 9 years ago

#9554 new enhancement

plain text download of wiki pages reveals comments not meant for public consumption

Reported by: Carsten Klein <carsten.klein@…> Owned by:
Priority: normal Milestone: next-major-releases
Component: wiki system Version: 0.12dev
Severity: normal Keywords: format plaintext
Cc: Thijs Triemstra Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Thijs Triemstra)

I find this one critical in that one might prototype content in the wiki that is not meant to be released to the public yet.

In order to reconstruct the scenario,

  1. create a new wiki page
  2. enter some content
  3. enter
    {{{
    #!comment
    TBD
    
    Critical information that must not yet be leaked to the public.
    }}}
    
    
  1. download as plain text

in the downloaded plain text you can see also the comment with content that was not yet meant to be consumed by the public.

Attachments (0)

Change History (9)

comment:1 by Remy Blank, 14 years ago

Priority: highnormal
Severity: criticalnormal

Err, if that content must not be leaked, don't put it into the page? That's certainly neither critical nor of high priority, as there is a simple, intuitive way of avoiding the issue.

What would you have expected, then?

  • That {{{#!comment}}} sections are stripped from the plaintext?
  • That it should be possible to disable the plain text download functionality?
  • Something else?

in reply to:  1 ; comment:2 by Christian Boos, 14 years ago

Keywords: format plaintext added
Milestone: next-major-0.1X
Owner: set to Christian Boos

Replying to rblank:

  • Something else?

I believe he expected to get the page formatted as plain text, which is indeed different than getting the wiki source. Once we have this feature, we could offer two download links: Wiki source and Plain Text, and only the latter when viewing read-only pages (i.e. for getting to the source, one should have the 'edit' permission).

I don't find another ticket for this right now, though it's pretty likely there's already one.

in reply to:  2 ; comment:3 by Carsten Klein <carsten.klein@…>, 14 years ago

Replying to cboos:

I believe he expected to get the page formatted as plain text, which is indeed different than

Correct.

getting the wiki source. Once we have this feature, we could offer two download links: Wiki source and Plain Text, and only the latter when viewing read-only pages (i.e. for getting to the source, one should have the 'edit' permission).

Nice idea, limiting access to the wiki source to only editors or admins.

Another point would be to allow the user to configure what kind of downloads are possible from a given resource realm, by making the downloaders components that can be switched on and off in the plugin configuration admin page.

in reply to:  3 comment:4 by Carsten Klein <carsten.klein@…>, 14 years ago

Replying to Carsten Klein <carsten.klein@…>:

Another point would be to allow the user to configure what kind of downloads are possible from a given resource realm, by making the downloaders components that can be switched on and off in the plugin configuration admin page.

I guess the functionality is already there: cf. the trac.mimeview.api module where we have the WikiTextRenderer :)

And, since the renderer is already a component, everything said above is already available and should just be utilized.

My proposal would be that the mimeview module also provides for a IRequestHandler component that will then accept requests to specific uris, such as /mimeview/wiki | /mimeview/ticket …, by which it then will delegate model retrieval to a yet to be determined interface or rather implementation thereof, e.g. a resource handler or something similar.

After having called the resource handler's get_content() method, it will then try to find a suitable handler for the requested format, i.e. the original format for the wiki is for example x-application-trac-wiki, and the requested format would be for example text/plain.

Sampel Call Sequence

Incoming Request → Main Request Dispatcher → MimeViewRequestHandler → find_resource_handler → get_content_and_default_mimetype_from_handler → find_converter → find_renderer → render_output

In addition, the currently insource definition of the mimetypes should be externalized. There is already a mimetypes module available that provides an extensible mimetypes database.

in reply to:  1 comment:5 by Carsten Klein <carsten.klein@…>, 14 years ago

Replying to rblank:

Err, if that content must not be leaked, don't put it into the page? That's certainly neither critical nor of high priority, as there is a simple, intuitive way of avoiding the issue.

Hm, in the documentation on the {{{#!comment}}} processor it states that contained content will not be rendered out. Of course, a normal user like myself would expect this to be true under all circumstances, especially when downloading a plain text representation of a given wiki page.

And, as for leaving out the information instead of putting it into a comment, I'd rather not. Consider, sometimes you have ideas on the content that must be further developed and which may also contain information that is not yet ready for public consumption. Keeping that information in a different place would place additional burden on the person maintaining the wiki pages, since the information that is kept in a different place must constantly be synchronized with the information on the actual wiki pages. Also, you will have two different histories for the same information, the one contained in the wiki page and the externally stored information. Whereas, if you kept them in a single place, you could easily track the history of both the public information and the one under development hidden in some comment.

comment:6 by Thijs Triemstra <lists@…>, 14 years ago

Cc: lists@… added

comment:7 by anonymous, 14 years ago

If one is using the AccessMacro hack it's getting even worse :/

Error: Failed to load processor access
No macro or processor named 'access' found

comment:8 by Thijs Triemstra, 14 years ago

Cc: Thijs Triemstra added; lists@… removed
Description: modified (diff)

Can you post a link to page that can display that macro, because it's not installed here.

comment:9 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.