Revision history for MagicWords
Revision [19183]
Last edited on 2008-01-28 00:14:41 by JonAmgine [Modified links pointing to docs server]No Differences
Additions:
One method brought up in IRC discussion was to provide an alternative markup which could be used to tell the parser to replace the content with the value of a system variable. Placing the variable name inside doubled greaterthan / lessthan symbols leaves it readily parsed and simply substituted. e.g. **<<tag>>** would be substituted with the pagename. This could provide a security risk without some method for blacklisting/whitelisting variables available since the database username and password would theoretically be available, as well as other vulnerabilities.
A second method is more complex, but provides both for greater security and greater security risk: provide an interface for designing magic words on a system. A simple MySQL table could be created with variable names and their substitution values such as:
{{table columns="2" cellpadding="1" cells="VAR;SUBSTITUTE;pagename;$tag;dayofweek;date('l')"}}
Clearly this second method introduces the possibility of php insertion vulnerabilities, so should not be a browser-editable item although I could see such a system being implemented using a wiki page.
== Discuss ==
Please discuss.
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered.
A second method is more complex, but provides both for greater security and greater security risk: provide an interface for designing magic words on a system. A simple MySQL table could be created with variable names and their substitution values such as:
{{table columns="2" cellpadding="1" cells="VAR;SUBSTITUTE;pagename;$tag;dayofweek;date('l')"}}
Clearly this second method introduces the possibility of php insertion vulnerabilities, so should not be a browser-editable item although I could see such a system being implemented using a wiki page.
== Discuss ==
Please discuss.
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered.
Deletions:
Additions:
One method brought up in IRC discussion was to provide an alternative markup which could be used to tell the parser to replace the content with the value of a system variable. Placing the variable name inside doubled greaterthan / lessthan symbols leaves it readily parsed and simply substituted. e.g. **
Deletions:
A second method is more complex, but provides both for greater security and greater security risk: provide an interface for designing magic words on a system. A simple MySQL table could be created with variable names and their substitution values such as:
{{table columns="2" cellpadding="1" cells="VAR;SUBSTITUTE;pagename;$tag;dayofweek;date('l')"}}
Clearly this second method introduces the possibility of php insertion vulnerabilities, so should not be a browser-editable item although I could see such a system being implemented using a wiki page.
== Discuss ==
Please discuss.
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered.
Additions:
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered.
Deletions:
Additions:
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <:?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered. ::::
Deletions:
Additions:
One thing I forgot to mention is a substitution syntax. Having any magicwords scheme is going to slow down page parsing on view. Adding a substitution syntax will allow the variable value to be replace the magicword in the actual page source. Use the above example variables, {{subst:pagename}} and {{dayofweek}} would be replaced by the value of $tag and <:?php date('l') ?>, respectively. This syntax mirrors the mediawiki syntax, allowing for easier migration, but there may very well be a standard wikitax for the same concept which should be prefered.
Additions:
Clearly this second method introduces the possibility of php insertion vulnerabilities, so should not be a browser-editable item although I could see such a system being implemented using a wiki page.
Deletions:
No Differences
