8 Oct
2003
8 Oct
'03
9:54 p.m.
Hi John,
There is a bug when deleting pages. Here is a test
case:
1) Add a *Test* link to the Introduction page
2) Click the Page link to create a new Test page
3) Save the Test page
4) Go to the Information folder and "remove" the Test page
5) Go back to the Introduction page and click the Page link to create
a new
Test page
6) Save the new Test page
7) Go back to the Introduction page -- the Folder, Page, Resource
items are
still there. However the Information page contains a Test page. If you
click
the Page link again, it will create a Test1 page, but it won't update
the
Introduction page.
- This bug has been fixed. At the same time I have cleaned the code
with the internal links a little bit, as this was not the only case
where they showed wrong behavior. The look-up of the link-target is now
done dynamically whenever the page is rendered, so I am always
up-to-date. However the new implementation does not update
automatically when renaming the target. In a future version a visitor
could be added to fix that kind of problem. Of course I've also added
some new tests.
- I have added a couple of missing tests, especially for the serving
part with the chain-of-responsibility pattern. This raises the overall
coverage of the tests to about 75% immediately.
Also, the cache uses a simple scheme for assigning
keys (+1). Isn't
this
scheme too simple for web apps? For example, I could look at the page
source, and come up with callbacks that are likely to be valid. For
example,
if I see callbacks for 341-344, I could try evaluating code for 340.
This
might execute a callback for some other person. Shouldn't the keys be
some
large random number instead?
- The tricky thing about the callbacks is, that they have to be
evaluated in the right order. To archive this, I sort the callbacks
according to their number to make sure that they are evaluated in the
same order as they had been defined on the page. In most cases this is
no security-issue as the the global permission of the action is checked
before evaluating the callbacks. However, and in that part your
concerns were absolutely right, there are some links in the EditFolder
action that require special permission (remove, copy) and that had not
been checked properly before. I've added some additional code to handle
this.
The optimal solution would be to have a huge and random session key
combined with small callback-numbers unique to that session. Probably
this will come in the future, when there is a proper session support in
SmallWiki.
I've committed the changes to Cincom StORE.
Cheers,
Lukas
--
Lukas Renggli
http://renggli.freezope.org