Rename temoplates from tpl to tpl.php

[GoogleCodeExporter]

It may be a security-problem to name templates in .tpl, cause this templates 
accept php-code an keep templates-variables inside (which are feeded by 
php-vars).

I recommend to rename the templates in tpl.php for seccurity reasons.

Original issue reported on code.google.com by samuelsu...@gmail.com on 12 Jan 2012 at 6:50

[GoogleCodeExporter]

I don't really see the benefit here. We could just block the access to all 
*.tpl files with .htaccess. Then we have a lot less work and solved the same 
problem. Or do you see a problem with it?

Original comment by r.luthi...@gmail.com on 16 Jan 2012 at 2:23

[GoogleCodeExporter]

.htaccess may also be usable. But only for those, who has activate the use of 
.htaccess for their Webspace (some providers has disabled it)

Original comment by samuelsu...@gmail.com on 16 Jan 2012 at 2:34

[GoogleCodeExporter]

first, can someone test it smart accepts .tpl.php as template names

second - we already block access via .htaccess to the .tpl files
-- refer: 
http://code.google.com/p/simpleinvoices/source/browse/branches/stable-2011-2/.ht
access#3

Original comment by jus...@kelly.org.au on 17 Jan 2012 at 10:29

[GoogleCodeExporter]

If I am right then Simple Invoice will not work because the configuration 
within .htaccess is needed in order to have a fully functional SI.

Original comment by r.luthi...@gmail.com on 17 Jan 2012 at 10:57

[GoogleCodeExporter]

simple invoices will still work even if .htaccess is not present
-- recurring invoices/cron is the only thing that needs mod_rewrite (.htaccess)

.htaccess just makes things nicer

Original comment by jus...@kelly.org.au on 17 Jan 2012 at 11:10

[GoogleCodeExporter]

It is good that the TPL files are already protected by .htaccess. I opened this 
post because I think it will be difficult, if SI is growing, to carry such 
things later.

Good software should run with minimal requirements for a large part of the user.
Thats the magic of Apple (and i'm not a Apple-Fan!): Things have just to work, 
and not only on certain (or best) circumstances.

Become a CCD - make Software better! (http://clean-code-developer.de/)

Original comment by samuelsu...@gmail.com on 18 Jan 2012 at 9:01

[GoogleCodeExporter]

The link to a German website won't help here much. ;)

I think too that code should be clean etc. But when I started to work in this 
project everything was a lot worse. I and my employee managed not to solve all 
"uninitialised variables" messages. And from the next version on it should be 
possible to set the error level a lot higher. In other words. Your security 
point is right and it is something that we should think of at some point but we 
have a lot more other problems that should be addresses. And all those will 
make the code a lot cleaner too.

Original comment by r.luthi...@gmail.com on 18 Jan 2012 at 9:59

• Changed state: Open-Accepted
• Added labels: Component-SecurityI, Milestone-Sometime, Priority-Low, Type-Other