pvijayfullstack / enterprise-wiki Goto Github PK

2011/10/18
==========
Allow revision viewing
Add timestamp to file links for MediaWiki syntax

# TODO Add universal support for <file></file>
# TODO Add support for <email></email> tag (like <math></math>)
# TODO Help documentation
# FIXME Universal error messages not displayed (should be in application layouts)
# TODO Compare revisions
# TODO Add file uploading entry UI/page
# TODO Add tests
# TODO Extend markup using Liquid to allow programmable pages
# TODO Add online theme manager & editor
# TODO "Watch this page"
# TODO Add universal markup editor


2011/10/17
==========
Add sqlite3 db file backup: /etc/cron.hourly/bakwiki
  #!/bin/sh
  backupdir=/bak/wikidata
  time=` date +%Y%m%d `
  cp /webapps/Enterprise-Wiki/db/production.sqlite3 $backupdir/production$time.sqlite3


2011/09/28
==========
Add secret_before to pages (only when page is public)


2011/09/10
==========
Add alias support by using Page model
Add sitemap /site/map


2011/09/02
==========
Remember last used markup
Remember last used theme


2011/09/01
==========
Implement sidebar with page model (instead of a separate model)
  page "/somepath" with sidebar page "/somepath:sidebar"
Search sidebar level by level
  page "/a/b" will use "/a:sidebar" if "/a/b:sidebar" doesn't exist
Go back to the last accessible page after signed in
  save request.fullpath in session[:last_page_path]


2011/08/31
==========
Add sidebar
Paths are not escaped when saving to database (or will cause too-long-path problem)
  Now works well with Apache and Passenger


2011/08/30
==========
Fix some bugs in templates and about content_for :title
"This is a minor edit"
Add CSS style for page history (table.history ...)
Fix logout functionality in monobook theme (routing error)
  => add <%= javascript_include_tag :defaults %> to application layout
Prototype works with jQuery now.


2011/08/28
==========
Modify monobook theme (change sidebar, portlets, etc.)
Beautify forms (editing, uploading, etc.)


2011/08/27
==========
Add themes for ACM class and Enterprise Wik itself
Add MediaWiki theme (monobook)


2011/08/25
==========
Add page previewing
Add fixtures
Add syntax highlighting with Pygments and Albino


2011/08/21
==========
Special title syntax mechanism is replaced by creating special markup types.
I think it will be a better way for doing this.

Since files uploaded by different user are stored in different sub-directories,
the new file name can be a digest just like MD5(original_name + timestamp)

Page model with file type/markup uses title as the parameter to send_file,
i.e. the file name provided to the browser for naming local download copy.

Commit messages are optional.


2011/08/20
==========
Use title field of page model to identify different type of underlying model (page, file, etc.)
Page's title is normal
Special title syntax identified: "@[[XXX]]" e.g. "@[[FILE]]". I think it is special enough.

Serve plain texts as plain as possible
  So we can store javascript/css files in pages, and they can be edited directly online
Plain text files are identified like "@[[PLAIN]]"
Source codes are recommended to be stored as plain text files.


2011/08/19
==========
Restrict /admin access to super users (admin?)
Already deployed with LightTPD + FastCGI
About send_file and x-sendfile in Rails 3:
  http://vijaydev.wordpress.com/2010/12/15/rails-3-and-apache-x-sendfile/

According to many sources, especially http://stackoverflow.com/questions/735147/,
I decided to create three different models for files.
* Public/static files: they are not versioned and stored directly in places like
  "#{Rails.root}/public/files/xj/ia/xjia/avatar.png". Files are stored in different
  directories for different users in order to prevent illegal (unexpected) file
  overwritten under the unversioned circumstance. Directory structure is layered into
  three levels to prevent file system overloading which may be caused by too many files
  in the same directory. Suppose @name is the user's name and it is guaranteed that
  @name.length >= 4 according to the validation rules in the user model. Then the three
  layers are represented as "#{@name[0..1]}/#{@name[2..3]}/#{@name}/". This same
  technique is used in SourceForge project homepage hosting FTP as well. Note that
  public files are supposed to be small. They can be used for static assets by users.
* Protected files: they are stored in some place like "/data/enterprise-wiki/..."
  which is not accessible directly through the web server, and is controlled by our
  rails application. These files could benefit from X-Sendfile and thus be served
  with access control and without loss of performance. Protected files are versioned.
  There will be database tables for protected files in order to record the **mapped**
  file name, the slugified name, the editor, and timestamps. Protected files are also
  in layered directory structure, e.g. "/data/enterprise-wiki/xj/ia/xjia/XXX", in which
  XXX is calculated as MD5(original_name + editor + timestamp). File extension is ignored.
  Each slugified name corresponds to a mapped file name, which is the public file path,
  e.g. "/courses/ppca/2011/my_report.pdf". People access files through paths like this,
  and here comes the content type information, especially the extension part. However,
  content length/size is left to LightTPD to determine. Protected files are supposed to
  be most of the meaningful files stored in the system. Note that file paths are just
  page paths, and access rules are the same: if the current user can edit a page with
  that path, he can upload a file there; and if the current user can read a page with
  that path, he can download a file there. In this sense, protected files can be 
  implemented directly using pages, or to say it better, pages can be enhanced to
  hold files. It is a good idea, isn't it?
* Private/secure files: they are stored in database, because they can not be accessible
  by the OS user running the web server at the physical machine. However, storing in
  database just makes it harder to be accessible, not entirely secure. Well, it's hard.
So, after written these considerations, I think only the "protected files" mentioned
above needs to be implemented. And it can be implemented using existing page model ;-)
Only more conditional checking in "edit" and "show" actions. Pretty good. Fine enough.
Sleepy. Write it tomorrow.


2011/08/18
==========
Add role model: title:string
Change prefix_rule model: role_id:integer prefix:string action_name:string

Page show:
* if can edit this page, bypass (if not, can view by editing which is the same)
* if PRIVATE, check prefix rules
* if PROTECTED, only signed in users allowed
* otherwise, it is public to all

Add markups for page body. Reference https://github.com/github/markup

.markdown -- https://github.com/tanoku/redcarpet
    Why Redcarpet: https://github.com/blog/832-rolling-out-the-redcarpet
.textile -- gem install RedCloth
    RedCloth.new(content).to_html
.rdoc -- gem install rdoc -v 3.6.1
    https://github.com/github/markup/blob/master/lib/github/markup/rdoc.rb
.org -- gem install org-ruby
    Orgmode::Parser.new(content).to_html
.creole -- gem install creole
    Creole.creolize(content)
.mediawiki -- gem install wikicloth
    WikiCloth::WikiCloth.new(:data => content).to_html(:noedit => true)
OTHERWISE -- PLAIN TEXT

Add <math> support using MathJax
--------------------------------
* Some markups will process <math> (e.g. MediaWiki) 
  or escape <math> tag (e.g. Creole), but they do not care backslashes.
  In this case, just replace <math> with \( and </math> with \)
* Some markups will process backslashes, but they allow HTML-like tags
  and do not care the embedded contents in these tags, e.g. Markdown.
  In this case, leave <math> tags and process the markup itself first.
  After it is converted into HTML, replace <math> tags with \( and \)
* Some markups will escape <math> tags, and they also process backslashes.
  RDoc works this way and it is really bothering. I handle it manually
  by replacing \ with \\ between <math> and </math>


2011/08/17
==========
Wanna check permissions when editing pages.
Two kinds of pages: personal and normal.
Personal pages' paths start with a tilde.

Personal Page Rules
-------------------
* bypass super-user (e.g. root)
* bypass page owner (i.e. "~xxx" xxx == current_user)
* forbid others

Normal Page Rules
-----------------
* bypass super-user (e.g. root)
* bypass white list (check prefix, i.e. starts_with?)
* forbid others

Add new model PrefixRule: user_id:integer prefix:string


2011/08/16
==========
Wanna add pages.
page: path:string title:string body:text editor:string revision:integer

HTTP Digest Authentication
--------------------------
* The client asks for a page that requires authentication 
  but does not provide a username and password. Typically 
  this is because the user simply entered the address or 
  followed a link to the page.
* The server responds with the 401 "client-error" response 
  code, providing the authentication realm and a randomly-
  generated, single-use value called a nonce.
* At this point, the client will present the authentication 
  realm (typically a description of the computer or system 
  being accessed) to the user and prompt for a username and 
  password. The user may decide to cancel at this point.
* Once a username and password have been supplied, the client 
  re-sends the same request but adds an authentication header 
  that includes the response code.
* In this example, the server accepts the authentication and 
  the page is returned. If the username is invalid and/or the 
  password is incorrect, the server might return the "401" 
  response code and the client would prompt the user again.

The "response" value is calculated in three steps, as follows. 
Where values are combined, they are delimited by colon symbols.
* The MD5 hash of the combined username, authentication realm 
  and password is calculated. The result is referred to as HA1.
* The MD5 hash of the combined method and digest URI is calculated, 
  e.g. of "GET" and "/dir/index.html". The result is referred to as HA2.
* The MD5 hash of the combined HA1 result, server nonce (nonce), 
  request counter (nc), client nonce (cnonce), quality of protection 
  code (qop) and HA2 result is calculated. The result is the "response" 
  value provided by the client.

See http://api.rubyonrails.org/classes/ActionController/HttpAuthentication/Basic.html
for a coding example. The authenticate_or_request_with_http_digest 
block must return the user's password or the ha1 digest hash so 
the framework can appropriately hash to check the user's credentials. 
Returning nil will cause authentication to fail.