| Re: Nested PHP [message #184874 is a reply to message #184873] |
Wed, 12 February 2014 13:11   |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/02/14 12:52, Adrian Tuddenham wrote:
>> BTW - to delete files, you use unlink(). See the documentation at
>>> www.php.net - it's the best reference around.
> I found that function and tried it, but the file didn't seem to go away
> - its name was still visible even after I updated the file listings in
> my ftp program. Eventually I deleted it manually by ftp.
>
> Perhaps I got something wrong or I didn't wait long enough before
> checking; I'll try again.
I found many issues when handling external files with PHP.
I conjectured that PHP caches files and filenames internally, only
flushing to disk on exit.
For example writing a file to disk didn't happen so that mysql could use
it in a load file command unless it was copy()ed first.
unlink() for a file generated within PHP did work. But the same is not
true of files outside of it that may not have write permission for
whatever process spawned PHP..
My response to these issues has been to insert binary data using a
hexadecimal number string, instead of load file, and to use the mysql
database as a repository for all data, rather than the native OS file
system.
Mysql at least has a single unique interface and will queue asynchronous
requests, so that it always does what it says on the tin.
AS far as access to PDFS go, the approach I would take is to put them in
a database too in a BLOB, and use a php script to serve them that
authenticates the user (as identified by a cookie) as valid, or returns
an unauthorised access code.
writing PHP for authorised users is not a noobs easiest task, but its is
one that needs to be mastered if you are going to make the distinction
between authorised and public access.,
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: Nested PHP [message #184875 is a reply to message #184821] |
Wed, 12 February 2014 14:33 |
Mr Oldies
Messages: 241
Registered: October 2013
Karma: 0
|
Senior Member |
|
|
On Mon, 10 Feb 2014 20:24:55 +0000, Adrian Tuddenham wrote:
> I am using a php program to generate and download a webpage as an HTML
> file, the HTML file draws its headers and navigation bar from another
> HTML file using some embedded php with an "include" command.
>
> The embedded php doesn't run when the file is downloaded, so the page
> appears in the browser without its headers or navigation.
>
> Is there a way of making the HTML file run the php or do I have to
> tackle this from another angle?
If I understand this correctly, try naming the html file as php.
Any time you "include" another file you are using php.
Instead of include, try an iframe.
That way, the main page will be named html while the iframe page is php.
Style te iframe with no borders and nobody knows the difference.
|
|
|
|
| Re: Nested PHP [message #184882 is a reply to message #184875] |
Thu, 13 February 2014 06:47 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Wed, 12 Feb 2014 09:33:46 -0500, richard wrote:
> If I understand this correctly ...
Shut the fuck up, you have no idea what the OP wants to do or how to fix
it!
Seriously, you have no place offering anyone advice on php, mysql,
javascript, html or css, and need to learn to keep your idiot ideas to
yourself.
It's reading crap like you post and erroneously believing it to be
correct that gets you into the screwups you regularly suffer in the first
place. You really shouldn't be perpetuating the same crap by
regurgitating it at others.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Nested PHP [message #184883 is a reply to message #184873] |
Thu, 13 February 2014 06:55 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Wed, 12 Feb 2014 12:52:49 +0000, Adrian Tuddenham wrote:
> You couldn't really say the
> statements contained 'errors', they were just complete gobbledeygook
> made up by an author with no knowledge of the subject whatsoever.
Yes, that would describe the majority of richard's code too. When he
finally gets all the syntax errors sorted out, he's invariably left with
a pile of syntactically correct gobbledeygook, which he then insists
proves that php is broken because it doesn't actually do what he wants
(invariably because he hasn't written code that does what he actually
wants, he's written code that he thinks should do what he wants, and the
two are about as close together as Voyager1 and Curiosity).
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Nested PHP [message #184886 is a reply to message #184882] |
Thu, 13 February 2014 13:01 |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2/12/14, 10:47 PM, Denis McMahon wrote:
> On Wed, 12 Feb 2014 09:33:46 -0500, richard wrote:
>
>> If I understand this correctly ...
>
> Shut the fuck up, you have no idea what the OP wants to do or how to fix
> it!
>
> Seriously, you have no place offering anyone advice on php, mysql,
> javascript, html or css, and need to learn to keep your idiot ideas to
> yourself.
>
> It's reading crap like you post and erroneously believing it to be
> correct that gets you into the screwups you regularly suffer in the first
> place. You really shouldn't be perpetuating the same crap by
> regurgitating it at others.
>
One word for you Dennis.
Decaf..;)
|
|
|
|
| Re: Nested PHP [message #184892 is a reply to message #184883] |
Thu, 13 February 2014 18:02 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 13 Feb 2014 06:55:17 +0000 (UTC), Denis McMahon wrote:
> Yes, that would describe the majority of richard's code too. When he
> finally gets all the syntax errors sorted out, he's invariably left with
> a pile of syntactically correct gobbledeygook, which he then insists
> proves that php is broken because it doesn't actually do what he wants
> (invariably because he hasn't written code that does what he actually
> wants, he's written code that he thinks should do what he wants, and the
> two are about as close together as Voyager1 and Curiosity).
But it said "Space Probe" on the box! Why don't I feel it probing?
--
_ o
|/)
|
|
|
|
| Re: Nested PHP [message #184903 is a reply to message #184886] |
Fri, 14 February 2014 15:19 |
Evan Platt
Messages: 124
Registered: November 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 13 Feb 2014 05:01:44 -0800, Scott Johnson
<noonehome(at)chalupasworld(dot)com> wrote:
> One word for you Dennis.
>
> Decaf..;)
No, it's richard bullis. The bitchslap is well deserved.
He is always giving wrong and often even dangerous advice to people.
--
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.
|
|
|
|
| Re: Nested PHP [message #184905 is a reply to message #184903] |
Fri, 14 February 2014 18:43 |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2/14/14, 7:19 AM, Evan Platt wrote:
> On Thu, 13 Feb 2014 05:01:44 -0800, Scott Johnson
> <noonehome(at)chalupasworld(dot)com> wrote:
>
>> One word for you Dennis.
>>
>> Decaf..;)
>
> No, it's richard bullis. The bitchslap is well deserved.
> He is always giving wrong and often even dangerous advice to people.
>
I did not disagree with a single word he said, it was joking, hence the ;)
Scotty
|
|
|
|
| Re: Nested PHP [message #185145 is a reply to message #184821] |
Sun, 02 March 2014 14:54 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Adrian Tuddenham, 2014-02-10 21:24:
> I am using a php program to generate and download a webpage as an HTML
> file, the HTML file draws its headers and navigation bar from another
> HTML file using some embedded php with an "include" command.
>
> The embedded php doesn't run when the file is downloaded, so the page
> appears in the browser without its headers or navigation.
PHP is only executed on the *server*. Any PHP which is "dynamically"
added as output will *not* be executed at all.
Example - if you have a file "test.php" and request it using the browser
via http://mydomain.example/test.php:
<?php
echo "Test";
?>
This will just output "Test".
BUT: If the same will adds additional PHP code it will just be sent to
the browser without any interpetation by the PHP runtime:
<?php
echo "echo \"My embedded test\";";
?>
If you really need to execute "dynamic" PHP, you have to use eval(),
which executes the code passed as parameter:
<?php
$mycode = "echo \"My embedded test\";";
eval($mycode);
?>
Even though this may work - the problem with eval() is, that it is
horrible to debug. You don't have just a script but a script generating
another script which will then be executed.
I recommend to think about what you want to solve and if it is really
neccessary to create "dyanamic" PHP on the fly.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de
|
|
|
|
| Re: Nested PHP [message #185146 is a reply to message #185145] |
Sun, 02 March 2014 18:10 |
adrian
Messages: 27
Registered: December 2012
Karma: 0
|
Junior Member |
|
|
Arno Welzel <usenet(at)arnowelzel(dot)de> wrote:
> Adrian Tuddenham, 2014-02-10 21:24:
>
>> I am using a php program to generate and download a webpage as an HTML
>> file, the HTML file draws its headers and navigation bar from another
>> HTML file using some embedded php with an "include" command.
>>
>> The embedded php doesn't run when the file is downloaded, so the page
>> appears in the browser without its headers or navigation.
>
> PHP is only executed on the *server*. Any PHP which is "dynamically"
> added as output will *not* be executed at all.
>
> Example - if you have a file "test.php" and request it using the browser
> via http://mydomain.example/test.php:
>
> <?php
> echo "Test";
> ?>
>
> This will just output "Test".
>
> BUT: If the same will adds additional PHP code it will just be sent to
> the browser without any interpetation by the PHP runtime:
>
> <?php
> echo "echo \"My embedded test\";";
> ?>
>
> If you really need to execute "dynamic" PHP, you have to use eval(),
> which executes the code passed as parameter:
>
> <?php
> $mycode = "echo \"My embedded test\";";
>
> eval($mycode);
> ?>
>
> Even though this may work - the problem with eval() is, that it is
> horrible to debug. You don't have just a script but a script generating
> another script which will then be executed.
>
> I recommend to think about what you want to solve and if it is really
> neccessary to create "dyanamic" PHP on the fly.
I've now solved the problem a different way which avoids this
difficulty.
Thanks to all who helped.
--
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk
|
|
|
|
| Re: Nested PHP [message #185155 is a reply to message #185145] |
Mon, 03 March 2014 11:38 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 02/03/14 14:54, Arno Welzel wrote:
> Adrian Tuddenham, 2014-02-10 21:24:
>
>> I am using a php program to generate and download a webpage as an HTML
>> file, the HTML file draws its headers and navigation bar from another
>> HTML file using some embedded php with an "include" command.
>>
>> The embedded php doesn't run when the file is downloaded, so the page
>> appears in the browser without its headers or navigation.
>
> PHP is only executed on the *server*. Any PHP which is "dynamically"
> added as output will *not* be executed at all.
>
> Example - if you have a file "test.php" and request it using the browser
> via http://mydomain.example/test.php:
>
> <?php
> echo "Test";
> ?>
>
> This will just output "Test".
>
> BUT: If the same will adds additional PHP code it will just be sent to
> the browser without any interpetation by the PHP runtime:
>
> <?php
> echo "echo \"My embedded test\";";
> ?>
>
> If you really need to execute "dynamic" PHP, you have to use eval(),
> which executes the code passed as parameter:
>
> <?php
> $mycode = "echo \"My embedded test\";";
>
> eval($mycode);
> ?>
>
> Even though this may work - the problem with eval() is, that it is
> horrible to debug. You don't have just a script but a script generating
> another script which will then be executed.
>
it ain't that bad: the errors show up as error in eval script called on
line X: error in evalled script on line Y
So you at least know what the errors is and where it is.
Gets more interesting if your evalled script also evals more script..
> I recommend to think about what you want to solve and if it is really
> neccessary to create "dyanamic" PHP on the fly.
>
Nice thing about evalled code is that you can stick it in a database..
>
>
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: Nested PHP [message #185309 is a reply to message #185155] |
Mon, 17 March 2014 14:26 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Am 03.03.2014 12:38, schrieb The Natural Philosopher:
> On 02/03/14 14:54, Arno Welzel wrote:
>> Adrian Tuddenham, 2014-02-10 21:24:
>>
[About eval()]
>> I recommend to think about what you want to solve and if it is really
>> neccessary to create "dyanamic" PHP on the fly.
>>
> Nice thing about evalled code is that you can stick it in a database..
You call it "nice" to put *code* in a database? I would call it an ugly
hack.
I know, some products like vBulletin do this in production environments
- they put all their plugins and some other stuff in the database.
But this does not mean this is "nice" nor even something you want. Even
WordPress does not try to put code into the database ;-)
This is only a hack for situations where a plugin installer in the
administrative backend may not be able to write the files.
Some may this even call more "secure" since you can set the folder
permissions more restrictive. Some may call this more "comfortable"
since you don't need to give the web server permissions to write to the
document root. But in the end - it doesn't matter if an attacker is able
to overwrite files or overwrite database content, and securing the
database is not as easy as protecting the filesystem.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: Nested PHP [message #185310 is a reply to message #185309] |
Mon, 17 March 2014 14:52 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/17/2014 10:26 AM, Arno Welzel wrote:
> Am 03.03.2014 12:38, schrieb The Natural Philosopher:
>
>> On 02/03/14 14:54, Arno Welzel wrote:
>>> Adrian Tuddenham, 2014-02-10 21:24:
>>>
> [About eval()]
>>> I recommend to think about what you want to solve and if it is really
>>> neccessary to create "dyanamic" PHP on the fly.
>>>
>> Nice thing about evalled code is that you can stick it in a database..
>
> You call it "nice" to put *code* in a database? I would call it an ugly
> hack.
>
> I know, some products like vBulletin do this in production environments
> - they put all their plugins and some other stuff in the database.
>
> But this does not mean this is "nice" nor even something you want. Even
> WordPress does not try to put code into the database ;-)
>
> This is only a hack for situations where a plugin installer in the
> administrative backend may not be able to write the files.
>
> Some may this even call more "secure" since you can set the folder
> permissions more restrictive. Some may call this more "comfortable"
> since you don't need to give the web server permissions to write to the
> document root. But in the end - it doesn't matter if an attacker is able
> to overwrite files or overwrite database content, and securing the
> database is not as easy as protecting the filesystem.
>
>
>
+1
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Nested PHP [message #185312 is a reply to message #184821] |
Mon, 17 March 2014 15:18 |
Gabriel
Messages: 11
Registered: March 2014
Karma: 0
|
Junior Member |
|
|
On 10/02/2014 20:24, Adrian Tuddenham wrote:
> I am using a php program to generate and download a webpage as an HTML
> file, the HTML file draws its headers and navigation bar from another
> HTML file using some embedded php with an "include" command.
>
> The embedded php doesn't run when the file is downloaded, so the page
> appears in the browser without its headers or navigation.
>
> Is there a way of making the HTML file run the php or do I have to
> tackle this from another angle?
>
Hi Adrian
If you have downloaded the HTML file in your PHP script and stored it as
a variable named $html then you could make sure the PHP contained within
it is executed by running it through the eval() function:
<?php
$html = '' # Downloaded string data
ob_clean();
eval('?>' . $html); # Execute HTML string data that contains PHP
# Capture the HTML file after the PHP in it has been executed.
$output = ob_get_clean();
# Force download of generated HTML to user browser
header('Content-type: text/html');
# Call the file generated.html
header('Content-Disposition: attachment; filename="generated.html"');
echo $output;
Some notes apply, using eval() is extremely dangerous. You should only
use it if... actually you should never use it and find a different way
instead. If you are at all unsure as to what you are doing and the
security implications then you should avoid it. You should also avoid
running any PHP that is downloaded from another site or source over
which you do not have complete and total control. You really need to
take in to account the warning on the PHP site:
http://www.php.net/manual/en/function.eval.php
Cheers
Gabe
|
|
|
|
| Re: Nested PHP [message #185313 is a reply to message #185309] |
Mon, 17 March 2014 15:33 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 17/03/14 14:26, Arno Welzel wrote:
> Am 03.03.2014 12:38, schrieb The Natural Philosopher:
>
>> On 02/03/14 14:54, Arno Welzel wrote:
>>> Adrian Tuddenham, 2014-02-10 21:24:
>>>
> [About eval()]
>>> I recommend to think about what you want to solve and if it is really
>>> neccessary to create "dyanamic" PHP on the fly.
>>>
>> Nice thing about evalled code is that you can stick it in a database..
>
> You call it "nice" to put *code* in a database? I would call it an ugly
> hack.
>
That is because what you are trying to achieve is not necessarily what I
am trying to achieve.
What does a data base do well?
- breaks the directory hierarchy of data
- moves the data outside of the actual era directly accessible to te web
server
- provides a one point of backup
- adds a security of access to the data and code not easily done in
other ways.
In what I am working on, the advantages massively out weigh the
disadvantages. Depending on the user login on this uber secure site, not
only can they not see certain data, but the programs they can even
execute are different, at three levels - I can configure them not to be
accessible in any menus, and more to the point, even knowing their URL
doesn't help, because to a user without permissions they are not just
not executable, they don't actually exist - the server will return a
'not found' if they try.
And at the third level I can set SQL permissions so that if a program
bug renders than accessible, they cant be loaded with the SQL
permissions the user has either. So that will throw a PHP/SQL errors and
that helps me trace when I have the wrong code operating.
It gets better. Simply uploading malware into the web server hierarchy
wont change the way the site behaves. Code has to be uploaded through a
custom interface that isn't even on the same site as the web server, and
all code changes can be recorded in the same database.
Code and data are separately modified through secure programs designed
to allow just enough access to do the job. The code and data are not
mixed up so that any person 'designing a website' can screw the whole
operation up accidentally.
> I know, some products like vBulletin do this in production environments
> - they put all their plugins and some other stuff in the database.
>
> But this does not mean this is "nice" nor even something you want. Even
> WordPress does not try to put code into the database ;-)
>
What you want depends on what you are building.
Wordpress has to work in a situation where all you have is an
administrative front end or a an ftp access TO THE SAME SITE in place.
That is already completely broken security wise.
I only administer the PUBLIC site and code via a secure encrypted
connection to another site entirely.
Now that doesn't necessarily necessitate moving the code from a private
hierarchy visible to PHP alone, but the ability to completely map any
URL to any piece of code as well as to utterly disguise the fact that it
is actually PHP in play, is very handy.
It also means that in the limit I can encrypt the code in the database.
All bar the decryption algo of course..and that means that even the
sysadmins on the machine in its data centre cant have simple easy
accidental access in a Snowden kind of way to reveal much about the site.
They can't say 'we were routinely exposed to the data' any attempt to
decode it has to be a deliberate de facto criminal act.
In my case its a way to access intensely private and sensitive data in
the most secure and hack proof way possible whilst still having the
ability to expose very selected parts of it to the pubic at large, and
its also provides very de-skilled tools to manage that data at various
different levels, and many tools to allow the monitoring of who is
changing the code or data, when, and what IP address they are using.
Its a very secure very private cloud.
> This is only a hack for situations where a plugin installer in the
> administrative backend may not be able to write the files.
>
> Some may this even call more "secure" since you can set the folder
> permissions more restrictive. Some may call this more "comfortable"
> since you don't need to give the web server permissions to write to the
> document root. But in the end - it doesn't matter if an attacker is able
> to overwrite files or overwrite database content, and securing the
> database is not as easy as protecting the filesystem.
>
>
The important thing is that it should be very very hard for an attacker
to gain any foothold without being detected.
Unless he manges to gain root access to the actual server, in my case
the ONLY way is to use the 'staff entrance' which is very heavily
monitored.
I am not saying he can't get root access, but every way that he might
has at least one trap set.
At the moment the weak point is that the server is only a virtual
private server, in someone elses machine room on someone else's
hardware., and beyond the prototype I can envisage it being on a
securely-located-in-customers-own-premises physical machine on the end
of a high speed line.
That removes the major secuity hazard of outsourced hosting.
>
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: Nested PHP [message #185315 is a reply to message #185313] |
Mon, 17 March 2014 22:10 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 17 Mar 2014 15:33:13 +0000, The Natural Philosopher wrote:
> What does a data base do well?
> - breaks the directory hierarchy of data
> - moves the data outside of the actual era directly accessible to te web
> server
> - provides a one point of backup
> - adds a security of access to the data and code not easily done in
> other ways.
Oh dear... Let's start with that SQL was developed to run on a machine
that had no directory hierarchy, had no web, didn't even really have
a concept of "file" that was distinct from "table", and backing stuff
up was a matter of "saving things", because you had no idea whether
something was in memory or disk and didn't care. The security wasn't
added on because the whole OS was pretty indistinguishable from the
database. Everything you've mentioned is a side-effect of the database,
not intrinsic to its use. You wanna run at this again? Nevermind,
I'll just tell you. A database allows you to separate data from
application in a way that allows you to change the data, including its
interdependant relationships and qualities, without necessarily changing
the application.
The data comes first. Anytime you're starting with the application
first, you're working not with a database, but rather with a "storage
subsystem". Which is all fine and dandy, but it slaps you with richard
problems forever, in varying severity, until you give up, start over
with the data, and do it right.
--
34. I will not turn into a snake. It never helps.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: Nested PHP [message #185317 is a reply to message #185315] |
Mon, 17 March 2014 23:01 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 17/03/14 22:10, Peter H. Coffin wrote:
> On Mon, 17 Mar 2014 15:33:13 +0000, The Natural Philosopher wrote:
>> What does a data base do well?
>> - breaks the directory hierarchy of data
>> - moves the data outside of the actual era directly accessible to te web
>> server
>> - provides a one point of backup
>> - adds a security of access to the data and code not easily done in
>> other ways.
>
> Oh dear... Let's start with that SQL was developed to run on a machine
> that had no directory hierarchy, had no web, didn't even really have
> a concept of "file" that was distinct from "table", and backing stuff
> up was a matter of "saving things", because you had no idea whether
> something was in memory or disk and didn't care. The security wasn't
> added on because the whole OS was pretty indistinguishable from the
> database. Everything you've mentioned is a side-effect of the database,
> not intrinsic to its use. You wanna run at this again? Nevermind,
> I'll just tell you. A database allows you to separate data from
> application in a way that allows you to change the data, including its
> interdependant relationships and qualities, without necessarily changing
> the application.
>
> The data comes first. Anytime you're starting with the application
> first, you're working not with a database, but rather with a "storage
> subsystem". Which is all fine and dandy, but it slaps you with richard
> problems forever, in varying severity, until you give up, start over
> with the data, and do it right.
>
ER no. Try actually taking of those spectacles or extreme prejudice and
reading what I wrote.
Teh databse was already there for data.
It now contians applicatoin in different tables because the tools
developed to manage secure and protecect the data can do exactly the
same job on the code.
Consider the problem
I have page called /aby/xyz that I want accessible to one user and
totalluy invisible to another.
At best htaccess makes it tricky and says 'not allowed' it wont ever say
'page doesn't exist'.
My users already live in a proper relational database.What is easier
than to write a slender shim that intercepts all access to the web
server, analyses them and decides who they are and what they can then
access? Using tables of privilege, proriory and area to give a
multidimensional; matrix of access. And the ability to return 'access
denied' or 'page not found' under my control if they try and access
something I don't want them to?
All of that is classic proper database use. IN the end I might of had a
table of php files cross correlated to the uri's I wanted them to appear
under. I might, but at the point I said 'sod it, why not stick the
code in the database as well, so its JUST a database call not a database
call then then INCLUDE the file. And the file might get deleted leaving
you with a database entry pointing to nothing. Stick it IN the database.
Code is after all data that has a special meaning, that's all.
I COLD have avoided eval by simply unloading the code onto disk,
executing it as a php include, then deleting it.
How crap is that?
I COULD have kept an audit trail on the code by giving every programmer
an actual linux login and letting them crawl around the host system, I
chose to rather write a tool that lets them upload code, only, and
tracks who uploaded when and where they uploaded it and why..a little
more security and a lot more logging than Linux does by itself.
Yo have been taught RuUles. 'never use eval'
Rules are for the guidance of wise men, and the obedience of fools. What
you think is that I am a richard, someone whose knowledge is minimal
compared to your own.
It never enters your head I might in fact be thirty years ahead of you.
And know EXACTLY what I am doing and have a very good reason based on
sound experience and several weeks of considering the options, does it?
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: Nested PHP [message #185318 is a reply to message #185317] |
Mon, 17 March 2014 23:31 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
The Natural Philosopher wrote:
> Consider the problem
>
> I have page called /aby/xyz that I want accessible to one user and
> totalluy invisible to another.
>
> At best htaccess makes it tricky and says 'not allowed' it wont ever say
> 'page doesn't exist'.
>
> My users already live in a proper relational database.What is easier
> than to write a slender shim that intercepts all access to the web
> server, analyses them and decides who they are and what they can then
> access? Using tables of privilege, proriory and area to give a
> multidimensional; matrix of access. And the ability to return 'access
> denied' or 'page not found' under my control if they try and access
> something I don't want them to?
Why not deploying the page controller pattern?
...
<?php
analyzeHit();
if (!userAuthorizedToViewThisPage()) {
header('HTTP/1.0 403 Forbidden');
exit;
}
?>
<!DOCTYPE html>
...
A front controller may be preferable (and it seems you're using
something like that), but that also doesn't require to store PHP code in
a database.
Actually, requiring authorization for delivering certain content is
quite common, but I doubt that there are (m)any sites storing PHP code
in a database for that reason. The only reason I can see for storing
PHP code in a DB, is to cater for user submitted code, what may be
useful for e.g. CMSs.
--
Christoph M. Becker
|
|
|
|
| Re: Nested PHP [message #185319 is a reply to message #185318] |
Tue, 18 March 2014 13:10 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 17/03/14 23:31, Christoph Michael Becker wrote:
> The Natural Philosopher wrote:
>
>> Consider the problem
>>
>> I have page called /aby/xyz that I want accessible to one user and
>> totalluy invisible to another.
>>
>> At best htaccess makes it tricky and says 'not allowed' it wont ever say
>> 'page doesn't exist'.
>>
>> My users already live in a proper relational database.What is easier
>> than to write a slender shim that intercepts all access to the web
>> server, analyses them and decides who they are and what they can then
>> access? Using tables of privilege, proriory and area to give a
>> multidimensional; matrix of access. And the ability to return 'access
>> denied' or 'page not found' under my control if they try and access
>> something I don't want them to?
>
> Why not deploying the page controller pattern?
>
> ...
> <?php
> analyzeHit();
> if (!userAuthorizedToViewThisPage()) {
> header('HTTP/1.0 403 Forbidden');
> exit;
> }
> ?>
> <!DOCTYPE html>
> ...
>
> A front controller may be preferable (and it seems you're using
> something like that), but that also doesn't require to store PHP code in
> a database.
>
> Actually, requiring authorization for delivering certain content is
> quite common, but I doubt that there are (m)any sites storing PHP code
> in a database for that reason. The only reason I can see for storing
> PHP code in a DB, is to cater for user submitted code, what may be
> useful for e.g. CMSs.
>
in the end it was a balance of issues that decided it.
Probably the killer reason was that having to use the database anyway
to see whether or not the code would be executed, I was left with a list
of code and 'stuff to do with this code' that would go in the database,
and it seemed to be entirely within the basic database principle that
you don't stick the thing and its attributes in two different places
when there is always a 1:1 relationship... so the code followed the
'attributes of this code' into the database.
That made eval the way to execute it.
Since the code is preformed anyway, there is no more danger in this than
any other method. I.e. I am not using eval to allow some user response
to execute arbitrary code. It is simply a 'subroutine call into a
database'. And almost entirely equivalent to using include()
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]