#5772 Allura Code Viewer: enable viewing documentation directly from the repository
Originally created by: dcommander
This is one of several tickets I am creating to log what I feel are shortcomings in the new (Allura) code viewer relative to the old (ViewVC) code viewer. In all of these cases, simply providing a way for users to continue using ViewVC would be an acceptable workaround.
Several of my projects rely on the ability to view static HTML and text documents directly in the repository so that different versions of these documents can easily be linked from our wiki. For instance:
http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vgl/tags/2.3.2/doc/index.html
http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/trunk/README-turbo.txt
http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/branches/1.2.x/doc/html/group___turbo_j_p_e_g.html
The new code viewer provides no way of doing that. The closest I can get with the new viewer is to provide a link for viewing the text files with line numbers and other decorations:
https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/trunk/README-turbo.txt
or for downloading the file (not displaying it in the browser):
https://sourceforge.net/p/libjpeg-turbo/code/HEAD/tree/trunk/README-turbo.txt?format=raw
But nothing can be done for HTML pages.
Suggested resolution:
Add a separate "view" mode for the file, perhaps implemented similarly to how you are implementing the History view. For instance:
Unless I miss my guess, this should allow static HTML pages and text documents in the repository to be displayed directly in the browser. In ViewVC, when displaying an in-tree HTML file, it will correctly link to any other HTML pages in the same repository as well as correctly display images in the same repository, provided that the links to them are all relative. Thus, the new viewer would need to do likewise.
Doing this for plain text files would be ok, but for security reasons we can't allow arbitrary HTML to be served up from our site. (It could include JS and since it's running on our main site, it'd have access to session cookies, etc).
Originally by: dcommander
Which is a good reason why the code viewer should not be running on the main site. ViewVC was a perfectly fine solution. I would be perfectly satisfied to run it in our project web space, if it were technically feasible to do so, but as you know, it isn't.
Security is all well and good, but when you have to introduce usability regressions in order to achieve it, that's never a good thing. The VirtualGL Project treats documentation as a product of our project, just as surely as if it were code. Thus, it is very important for us to be able to link to different revisions of it easily, and we will resist migrating to Allura for as long as we are able unless this functionality is implemented in the new platform. If this can't be done using the new code viewer, then let's work together to figure out how it might be achievable in some other way.
You're talking to someone who has nearly 20 years of industry experience in IT and software development, including in matters of security, so I am aware of the issues. I'm also aware that there are ways around them.
Originally by: jmvanel
My project doc on Subversion has an occasional JavaScript (showing the doc. actual timestamp), but if it's not available from sf.net , it's not a problem.
Originally by: dcommander
All of our documentation is completely static HTML, so it would not bother me to have Javascript and other niceties completely disabled in this proposed interface. We do use a different CSS, however, so the HTML would need to be displayed in a different window/tab rather than in line.
Need to determine whether to ensure security via content sanitization or host on separate subdomain (requires extra setup for all Allura installs?)
Another point of reference: Google Code supports it and uses a separate domain (googlecode.com vs code.google.com) Example: http://dropdown-check-list.googlecode.com/svn/trunk/doc/dropdownchecklist.html
Alternative for SVN is to use http:// URLs to the repository directly, and make sure that the html files have the svn:mime-type property set to text/html