[xwiki-devs] Why /templates not in /WEB-INF?
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
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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze < [email protected]> 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
Tiago Rinck Caveden wrote:
On Thu, Jun 12, 2008 at 9:53 AM, Lilianne E. Blaze < [email protected]> 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
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/
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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> 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/
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 <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/
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/
On Fri, Jun 13, 2008 at 5:13 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/
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
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
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 < [email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Lilianne E. Blaze -
Pascal Voitot -
Sergiu Dumitriu -
Tiago Rinck Caveden -
Vincent Massol