Open GoogleCodeExporter opened 9 years ago
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
.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
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
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
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
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
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
Original issue reported on code.google.com by
samuelsu...@gmail.com
on 12 Jan 2012 at 6:50