12 Jun
2008
12 Jun
'08
6:04 a.m.
Hello,
Is there any particular reason why /templates are not in /WEB-INF?
I don't like the idea of having part of the source code accessible by
everyone.
Greetings, Lilianne E. Blaze
12 Jun
12 Jun
8:56 a.m.
I see your point but, as an external XWiki user/developer (I'm not
committer), I think these are only velocity scripts containing useful
variables and parts of interaction code but no "core" core... These
scripts could be copied/pasted in any XWiki document... To my mind, the
important thing is not to hide these scripts but to verify they don't
contain any silly access control such as "if($hasRight)
doSomethingNeedingStrongSecurity()" because if you simply rewrite the script
without the test, you access what should be protected... The control should
be placed in the code...
Pascal
On 6/12/08, Lilianne E. Blaze <lilianne(a)lilianne-blaze.net> wrote:
Hello,
Is there any particular reason why /templates are not in /WEB-INF?
I don't like the idea of having part of the source code accessible by
everyone.
Greetings, Lilianne E. Blaze
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:53 a.m.
Hello,
Pascal Voitot wrote:
scripts could be copied/pasted in any XWiki
document... To my mind, the
important thing is not to hide these scripts but to verify they don't
I agree it's more important, but it's better to take a multi-layered
approach and both secure and hide the code. No point in showing (or
not-hiding) anything you don't need to show, no matter how trivial.
Pascal
Greetings, Lilianne
10:29 a.m.
On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze <
lilianne(a)lilianne-blaze.net> wrote:
Hello,
Pascal Voitot 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.
Best regards,
--
Tiago Rinck Caveden
http://caveden.multiply.com
scripts could be copied/pasted in any XWiki
document... To my mind, the
important thing is not to hide these scripts but to verify they don't
I agree it's more important, but it's better to take a multi-layered
approach and both secure and hide the code. No point in showing (or
not-hiding) anything you don't need to show, no matter how trivial.
10:45 a.m.
Tiago Rinck Caveden wrote:
On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze
<
lilianne(a)lilianne-blaze.net> wrote:
I partially agree. But it is LGPL, meaning it is possible to use it with
closed-code software. Some of the glue code will likely end up in
/templates, and not everyone will be comfortable with having said
glue-code viewable by public.
No matter, I think I have a pretty simple solution that doesn't require
any changes in XWiki source. I'll let you know when I'll have it ready.
Probably in 3-4 days tops.
Hello,
Pascal Voitot 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. scripts could be copied/pasted in any XWiki
document... To my mind, the
important thing is not to hide these scripts but to verify they don't
I agree
it's more important, but it's better to take a multi-layered
approach and both secure and hide the code. No point in showing (or
not-hiding) anything you don't need to show, no matter how trivial.
Best regards,
Greetings, Lilianne
13 Jun
13 Jun
3:17 p.m.
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/
4:49 p.m.
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?
Pascal
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/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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/
4:59 p.m.
I would be glad to do it but I'm on holiday next week ;)
Basically, some more doc would be great because I can imagine people can
feel a bit lost when digging into XWiki...
On Fri, Jun 13, 2008 at 4:54 PM, Vincent Massol <vincent(a)massol.net> wrote:
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/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:09 p.m.
Pascal Voitot wrote:
I would be glad to do it but I'm on holiday next
week ;)
Basically, some more doc would be great because I can imagine people can
feel a bit lost when digging into XWiki...
Well, next week is the second doc hour, so maybe someone could work on that.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5:13 p.m.
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?
[snip]
> 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.
The wiki document must have an XWiki.XWikiSkins object, and be set as the skin used in the
Global
Administration page.
The wiki object fields are fields of that object, and you can already see that the
XWikiSkins class
has fields for some templates, like footer.vm, edit.vm or view.vm.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5:22 p.m.
On Fri, Jun 13, 2008 at 5:13 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Pascal Voitot wrote:
:) I see...
You are really quick... I imagine something and immediately you give it to
me :)
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?
[snip]
> 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.
The wiki document must have an XWiki.XWikiSkins object, and be set as the
skin used in the Global
Administration page.
The wiki object fields are fields of that object, and you can already see
that the XWikiSkins class
has fields for some templates, like footer.vm, edit.vm or view.vm.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:33 p.m.
Pascal Voitot wrote:
I see your point but, as an external XWiki
user/developer (I'm not
committer), I think these are only velocity scripts containing useful
variables and parts of interaction code but no "core" core... These
scripts could be copied/pasted in any XWiki document... To my mind, the
important thing is not to hide these scripts but to verify they don't
contain any silly access control such as "if($hasRight)
doSomethingNeedingStrongSecurity()" because if you simply rewrite the script
without the test, you access what should be protected... The control should
be placed in the code...
The control usually is in the core, but templates contain this kind of checks to let the
user know
what he can / cannot do.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
12 Jun
12 Jun
9:14 a.m.
Hi Lilianne,
On Jun 12, 2008, at 6:04 AM, Lilianne E. Blaze wrote:
Hello,
Is there any particular reason why /templates are not in /WEB-INF?
I don't like the idea of having part of the source code accessible by
everyone.
They are content like any content file you put in your webapp root.
For example you would put JSP files there. The Velocity template are
the equivalent of JSP files but for Velocity. By content I mean files
that are allowed to be modified by the users of XWiki. You are free to
modify them and remove them.
In WEB-INF we put configuration data or files that are not content.
Also, why do you say they are accessible (assuming you mean writeable)
by everyone? AFAIK they are only accessible to those who have access
to the filesystem.
Thanks
-Vincent
9:54 a.m.
Hello,
Vincent Massol wrote:
Hi Lilianne,
They are content like any content file you put in your
webapp root.
For example you would put JSP files there. The Velocity template are
Well, yes and no. Users can't access .jsp sources, only what is
generated by them.
On the other hand these files are viewable, users see their code. Run
the hsqldb unzip-and-run version and check
http://localhost:8080/xwiki/templates/macros.vm - everything visible.
Of course there shouldn't be any 'secret' things inside them, like
passwords, but being able to view them might give someone an idea how to
attack the rest of the code. Think about the SQL injections - the more
you know about the code, the easier it is to try an sql injection
attack. If you see the html code the browser normally receives, they're
moderately difficult. If you see the .php source, even if it doesn't
contain any connection-specific data, it makes it much easier.
Of course it doesn't apply to an out-of-the-box XWiki as the source is
available anyway, but it can expose custom modifications.
As for .jsps, actually I do place them in /WEB-INF along with everything
else that doesn't absolutely have to be in / to work (like static
images, javascript, etc) behind a controller (Struts for example). And I
got the impression it's a pretty common practice.
Also, why do you say they are accessible (assuming you
mean writeable)
by everyone? AFAIK they are only accessible to those who have access
As in anyone-can-view-the-code, not as in writeable.
Thanks
-Vincent
Greetings, Lilianne
10:19 a.m.
In fact, the question is always: where is the limit between content and
code? what's presentation layer and what's business layer? :)
JSP should never contain any code in modern web architecture and only be
presentation layer...
PHP often mixes both but this can be limited using a good PHP framework...
Anyway JSP and PHP are always hidden and you only see the result.
XWiki allows putting Velocity scripts in any document (and soon Groovy).
Logic in content... Then where is the limit????... I would answer: where you
want it to be... There is no universal rule about this and I think this is
one strength of XWiki... You can change it in what you need...
But I see what you mean... it can be disturbing that people can directly see
VM scripts which seem to be the basic scripts of XWiki... I don't know the
exact point of view of Vincent about this but I think you can customize as
you want, it shouldn't be complicated...
br
Pascal
On Thu, Jun 12, 2008 at 9:54 AM, Lilianne E. Blaze <
lilianne(a)lilianne-blaze.net> wrote:
Hello,
Vincent Massol wrote:
Hi Lilianne,
They are content like any content file you put in
your webapp root.
For example you would put JSP files there. The Velocity template are
Well, yes and no. Users can't access .jsp sources, only what is
generated by them.
On the other hand these files are viewable, users see their code. Run
the hsqldb unzip-and-run version and check
http://localhost:8080/xwiki/templates/macros.vm - everything visible.
Of course there shouldn't be any 'secret' things inside them, like
passwords, but being able to view them might give someone an idea how to
attack the rest of the code. Think about the SQL injections - the more
you know about the code, the easier it is to try an sql injection
attack. If you see the html code the browser normally receives, they're
moderately difficult. If you see the .php source, even if it doesn't
contain any connection-specific data, it makes it much easier.
Of course it doesn't apply to an out-of-the-box XWiki as the source is
available anyway, but it can expose custom modifications.
As for .jsps, actually I do place them in /WEB-INF along with everything
else that doesn't absolutely have to be in / to work (like static
images, javascript, etc) behind a controller (Struts for example). And I
got the impression it's a pretty common practice.
Also, why do you say they are accessible
(assuming you mean writeable)
by everyone? AFAIK they are only accessible to those who have access
As in anyone-can-view-the-code, not as in writeable.
Thanks
-Vincent
Greetings, Lilianne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6353
days inactive
6354
days old
15 comments
5 participants
participants (5)
-
Lilianne E. Blaze -
Pascal Voitot -
Sergiu Dumitriu -
Tiago Rinck Caveden -
Vincent Massol