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

[Carsten Klein <carsten.klein@…>]

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.
   }}}
   
   

4. 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.

[Remy Blank]

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?

[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.

[Carsten Klein <carsten.klein@…>]

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.

[Carsten Klein <carsten.klein@…>]

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.

[Carsten Klein <carsten.klein@…>]

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.

[anonymous]

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

[Thijs Triemstra]

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