Messages

1

HTML & templates / Macros: problems with quotings

« on: April 24, 2008, 06:22:00 AM »

1. if you solve problem 2, you don't need to solve problem 1.

Actually, the condition two of question 1 is the important part: In order to use {.dequote to successfully unleash external macro execution, there must BE no quotes (bug?)

2. use {.dequote|{.load|file.}.}
it will just remove starting and ending :} (if present)
removing them will unleash the execution

By testing a little, I have found the following:
using {.load| only (no dequote) will just read out the file specified (if there are no {: :} tags).
Using {.load on a file with quotes seemingly stops macro execution for the remainder of the request. (in the Rawr template, this leaves a bunch of uninterpreted macro code visible on the page)

Using {.dequote|{.load| on a file that has any {: :} tags (macros included or not) also has the effect of "crashing" the macro interpreter.
However, using {.dequote|{.load| on a file that has macro commands but not comments will allow the external file's macros to be executed as expected.

By the way, I am testing this using build #185.
On a side note, how would I go about escaping the percent signs when writing using {.append or {.save?
The purpose of my problems is that I wish to try to save bandwidth by only allowing logged-in users to edit thier own posts, (currently the post is transfered twice, one for display, one for editing) and an example code that could do this is:

Code: [Select]

{.if|{.=|%user%|hard-coded-username.}|output editor code|otherwise don't do anything.} (in the outputted file)
Unfortunately, if I write %user% anywhere in a template or macro HFS of course interprets it and fills in the username  whether I want it to be written to a file or interpreted like normal .

I have setup a sandbox site to demonstrate what happens Here. I think all of the test posts inside are named the same (check using ?tpl=list&folders-filter=\&recursive)

2

HTML & templates / Macros: problems with quotings

« on: April 23, 2008, 05:10:10 AM »

  Just playing around with the templates macro function and I was trying to solve an "issue":
I have been working on creating a sort of "forum" using hfs. (almost usable)
During posting of a message (merely using a macro to write a folder (see the Rawr template's shoutbox example)) I write html code for the center text area in the files listing (in the Rawr template) to show the message.
This is the problem: Attempting to tell the {.append or {.save macros to save text with a macro in it (i.e. has {. in it) then HFS parses the macro before writing the file!
I understand this is on purpose as to the wiki: http://www.rejetto.com/wiki/index.php?title=HFS:_Template_macros#Problem
However, when using the proposed solution (wrapping it in {{\ /}} comment tags), the macros are indeed left untouched, but where the comment tags are are "{:" and ":}" (which I take to mean another way to comment out a macro).
The result of loading any file with these tags ( the {: :} ones) using {.load seems to crash the macro system for that page load, as all macros are left uninterpreted after the {.load statement (not to mention the {.load statement fails).
However, loading files with legitimate macro commands ({.if etc...) leaves the macros uninterpreted.

So:
1.) How do I write the code inside a {.append or {.save macro so that macros inside will be written uninterpreted (and apparently without {: :} tags)
2.) How do I load a file so that macro commands inside of it are interpreted?

Thanks,
Tsaukpaetra

3

Beta / Re: Testing build #185

« on: April 21, 2008, 04:49:40 AM »

In regards to the "run as Administrator problem":
Programs that are run as administrator cannot receive inter-process messages (like if you drag+drop files) from a program of a different session.

What I mean by this is that because you are running Hfs as an administrator, other programs are not allowed to interact with it (for security purposes).
The thought-line was that since a program running as an Administrator has TOTAL access to the computer, and malicious program could be written to take control of that application (worst case scenario of course) and use it do cause harm to the computer. For an example, if a worm was written to watch for programs that have the ability to display the standard windows' "Open File Dialog" box, it could send it's location into the FileName field, send an "Enter" and !Boom! it is running as an Administrator can can do /anything/.
Worst case scenario, right?

But anyways, this is most noticeable for accounts that are Standard level. It might not apply to accounts already Administrators.