Why /templates not in /WEB-INF?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Why /templates not in /WEB-INF?

Lilianne E. Blaze-2
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Pascal Voitot
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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

vmassol
Administrator
In reply to this post by Lilianne E. Blaze-2
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Lilianne E. Blaze-2
In reply to this post by Pascal Voitot
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


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Lilianne E. Blaze-2
In reply to this post by vmassol
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Pascal Voitot
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 <
[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Tiago Rinck Caveden
In reply to this post by Lilianne E. Blaze-2
On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze <
[hidden email]> wrote:

> 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.



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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Tiago Rinck Caveden
http://caveden.multiply.com
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Lilianne E. Blaze-2
Tiago Rinck Caveden wrote:

> On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze <
> [hidden email]> wrote:
>
>> 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.
>
>
>
> 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.

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.

>
> Best regards,

Greetings, Lilianne


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Sergiu Dumitriu-2
In reply to this post by Tiago Rinck Caveden
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Pascal Voitot
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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

vmassol
Administrator

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 <[hidden email]>  
> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Pascal Voitot
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 <[hidden email]> 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 <[hidden email]>
> > 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Sergiu Dumitriu-2
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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Sergiu Dumitriu-2
In reply to this post by Pascal Voitot
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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Pascal Voitot
On Fri, Jun 13, 2008 at 5:13 PM, Sergiu Dumitriu <[hidden email]> wrote:

> 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.


:) I see...
You are really quick... I imagine something and immediately you give it to
me :)


>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Why /templates not in /WEB-INF?

Sergiu Dumitriu-2
In reply to this post by Pascal Voitot
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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs