13 Jun
2008
13 Jun
'08
4:54 p.m.
On Jun 13, 2008, at 4:49 PM, Pascal Voitot wrote:
one question: would it even be possible to put all VM
scripts (maybe
not VM
Xwiki variables since they are part of the XWiki interface...)
directly in
the DB so that the admin can even modify the most basic XWiki scripts?
There's no need to do anything, this feature already exists. All vm
scripts can be overriden in a custom skin.
Note: This needs to be documented properly on the skin's page on
xwiki.org. If someone can do it that would be great.
Thanks
-Vincent
On Fri, Jun 13, 2008 at 3:17 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com>
wrote:
> Tiago Rinck Caveden wrote:
>>
>> XWiki is free software... The entire source is readable by the whole
>> world... and this is good!
>>
>> I think the opposite way actually. No point in hiding if there is no
>> important secret there. Spread the knowledge.
>>
>
> That is one of the things Open Source lists as a strong point, the
> ability
> to view the code and see
> how it works. Sure, people are afraid that attackers can see holes
> in the
> source and take advantage
> of them, but that is the closed source way of thinking. But it is
> well
> known that it never prevents
> attacks from happening. On the other hand, when the code can be
> seen by
> anyone, good hackers can
> detect those holes and provide patches for them before a bad
> cracker gets
> the idea to try and attack
> the site. The open model is always better.
>
> Let's put it this way, if an attacker wants to attack a site, he
> will do it
> with or without the
> code. If a good hacker wants to help, he won't do it if he has to
> reverse
> engineer. He can't provide
> a patch if he doesn't have something to patch first. So a hidden
> hole is
> more likely to remain a
> hole than an open one.
>
> Anyway, the way XWiki is made, the templates can be (re)placed in
> many
> ways, not only as files in
> /templates/, but as files in /skins/XYZ/, attachments to a wiki
> document,
> or fields in a wiki
> object. This makes XWiki the most flexible and customizable web
> development
> platform ever, but
> requires that you take care of your code, as it will always be open
> (for
> viewing).
>
> One solution around this would be to have a custom file with
> macros, placed
> in WEB-INF, and
> registered as a global macro file in velocity.properties (note that
> this
> doesn't work starting with
> 1.5, as global macros work differently in the new velocity
> component). The
> restriction is that only
> macros can be used that way, and not actual templates. You can,
> however,
> define each "template" code
> as a macro, and put only one macro call in the actual template file.
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/