Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12759 > unrolled thread

Nested PHP

Back to article view | Back to comp.lang.php

Contents

  Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-10 20:24 +0000
    Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 15:56 -0500
      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-10 21:44 +0000
        Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 16:51 -0500
          Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-11 08:14 -0600
            Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 09:27 -0500
              Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-11 18:41 -0600
                Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 20:03 -0500
                  Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 10:13 +0000
                    Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-12 10:33 +0000
                    Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-12 06:30 -0500
                      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 12:52 +0000
                        Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-02-12 13:11 +0000
                        Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-13 06:55 +0000
                          Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-13 12:02 -0600
                    Re: Nested PHP Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2014-02-12 12:14 +0000
        Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-02-10 22:09 +0000
        Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-10 23:23 +0100
        Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-10 22:27 +0000
        Re: Nested PHP Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-02-11 09:30 +1100
        Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-10 23:06 +0000
          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 20:46 -0500
            Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 10:11 +0000
              Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-11 11:17 +0000
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 12:01 +0000
                  Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-11 12:45 +0000
                    Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-11 13:55 +0100
                      Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-11 13:29 +0000
                        Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 14:31 +0000
                          Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-11 17:24 +0000
              Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 08:15 -0500
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 14:31 +0000
                  Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 10:10 -0500
                    Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 15:31 +0000
                      Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 11:24 -0500
                        Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 10:13 +0000
                          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-12 06:33 -0500
                  Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 15:26 +0000
              Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 14:41 +0000
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 15:31 +0000
                  Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 15:53 +0000
                  Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 11:26 -0500
        Re: Nested PHP bill <william@TechServSys.com> - 2014-02-11 07:12 -0500
    Re: Nested PHP richard <noreply@example.com> - 2014-02-12 09:33 -0500
      Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-13 06:47 +0000
        Re: Nested PHP Scott Johnson <noonehome@chalupasworld.com> - 2014-02-13 05:01 -0800
          Re: Nested PHP Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-02-14 07:19 -0800
            Re: Nested PHP Scott Johnson <noonehome@chalupasworld.com> - 2014-02-14 10:43 -0800
    Re: Nested PHP Arno Welzel <usenet@arnowelzel.de> - 2014-03-02 15:54 +0100
      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-03-02 18:10 +0000
      Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-03 11:38 +0000
        Re: Nested PHP Arno Welzel <usenet@arnowelzel.de> - 2014-03-17 15:26 +0100
          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-17 10:52 -0400
          Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-17 15:33 +0000
            Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-03-17 17:10 -0500
              Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-17 23:01 +0000
                Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-03-18 00:31 +0100
                  Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-18 13:10 +0000
    Re: Nested PHP Gabe <usenet@moojuice.net> - 2014-03-17 15:18 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#12767

On Mon, 10 Feb 2014 21:44:02 +0000, Adrian Tuddenham wrote:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
>> On 2/10/2014 3:24 PM, 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?

>> The PHP code in your generated file is only executed when the file is
>> processed as a web page.  This is done by the web server, based on the
>> file extension (default is .php; you do have that as the file
>> extension,
>> right?).

> Yes -  and the same code runs perfectly well with all its headers if the
> file is sitting on the server and I call it up with a browser.  It is
> only if I 'create' it on the fly from a php program that it doesn't work
> - the HTML runs but the php doesn't.

What happens is that php script is executed by a script processor in the 
server, and the output of the php script is delivered by the server as 
html.

>> Any other means of downloading the file (i.e. ftp) will not cause the
>> PHP code to be executed.

> I was using a browser to view it, but the source code was coming from a
> php program, not directly from a file on the server.

When you say "the source code was coming from a php program" do you mean 
that you were viewing a php script with a web browser, or do you mean 
that you were running a script through a php interpreter and viewing the 
output?

Any php processing for web pages that is needed is generally carried out 
in a process called from the main server process in the web server. 
Normally when a .php file is requested, the webserver passes the file to 
the php processor, and takes the output of the php processor and sends 
that to the requesting client as html (unless another content type is 
specified).

It's also possible for php to be embedded in html files, in which case 
the same thing happens for html files.

I can't quite map your description of what you're doing and what you seem 
to expect with my knowledge of how web servers work, this suggests that 
either you're using the terminology in a way that I don't understand, or 
possibly that your perception of what is happening is not what is 
actually happening.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12768

On 2/10/2014 6:06 PM, Denis McMahon wrote:
> On Mon, 10 Feb 2014 21:44:02 +0000, Adrian Tuddenham wrote:
>
>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>
>>> On 2/10/2014 3:24 PM, 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?
>
>>> The PHP code in your generated file is only executed when the file is
>>> processed as a web page.  This is done by the web server, based on the
>>> file extension (default is .php; you do have that as the file
>>> extension,
>>> right?).
>
>> Yes -  and the same code runs perfectly well with all its headers if the
>> file is sitting on the server and I call it up with a browser.  It is
>> only if I 'create' it on the fly from a php program that it doesn't work
>> - the HTML runs but the php doesn't.
>
> What happens is that php script is executed by a script processor in the
> server, and the output of the php script is delivered by the server as
> html.
>
>>> Any other means of downloading the file (i.e. ftp) will not cause the
>>> PHP code to be executed.
>
>> I was using a browser to view it, but the source code was coming from a
>> php program, not directly from a file on the server.
>
> When you say "the source code was coming from a php program" do you mean
> that you were viewing a php script with a web browser, or do you mean
> that you were running a script through a php interpreter and viewing the
> output?
>
> Any php processing for web pages that is needed is generally carried out
> in a process called from the main server process in the web server.
> Normally when a .php file is requested, the webserver passes the file to
> the php processor, and takes the output of the php processor and sends
> that to the requesting client as html (unless another content type is
> specified).
>
> It's also possible for php to be embedded in html files, in which case
> the same thing happens for html files.
>
> I can't quite map your description of what you're doing and what you seem
> to expect with my knowledge of how web servers work, this suggests that
> either you're using the terminology in a way that I don't understand, or
> possibly that your perception of what is happening is not what is
> actually happening.
>

Denis,

 From what I can gather, he's generating a page which contains PHP code 
from another PHP script, and sending the generated page to the browser - 
expecting the generated PHP code to be executed (which, of course, it 
isn't).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12772

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/10/2014 6:06 PM, Denis McMahon wrote:
> > On Mon, 10 Feb 2014 21:44:02 +0000, Adrian Tuddenham wrote:
> >
> >> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> >>
> >>> On 2/10/2014 3:24 PM, 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?
> >
> >>> The PHP code in your generated file is only executed when the file is
> >>> processed as a web page.  This is done by the web server, based on the
> >>> file extension (default is .php; you do have that as the file
> >>> extension,
> >>> right?).
> >
> >> Yes -  and the same code runs perfectly well with all its headers if the
> >> file is sitting on the server and I call it up with a browser.  It is
> >> only if I 'create' it on the fly from a php program that it doesn't work
> >> - the HTML runs but the php doesn't.
> >
> > What happens is that php script is executed by a script processor in the
> > server, and the output of the php script is delivered by the server as
> > html.
> >
> >>> Any other means of downloading the file (i.e. ftp) will not cause the
> >>> PHP code to be executed.
> >
> >> I was using a browser to view it, but the source code was coming from a
> >> php program, not directly from a file on the server.
> >
> > When you say "the source code was coming from a php program" do you mean
> > that you were viewing a php script with a web browser, or do you mean
> > that you were running a script through a php interpreter and viewing the
> > output?
> >
> > Any php processing for web pages that is needed is generally carried out
> > in a process called from the main server process in the web server.
> > Normally when a .php file is requested, the webserver passes the file to
> > the php processor, and takes the output of the php processor and sends
> > that to the requesting client as html (unless another content type is
> > specified).
> >
> > It's also possible for php to be embedded in html files, in which case
> > the same thing happens for html files.
> >
> > I can't quite map your description of what you're doing and what you seem
> > to expect with my knowledge of how web servers work, this suggests that
> > either you're using the terminology in a way that I don't understand, or
> > possibly that your perception of what is happening is not what is
> > actually happening.
> >
> 
> Denis,
> 
>  From what I can gather, he's generating a page which contains PHP code
> from another PHP script, and sending the generated page to the browser -
> expecting the generated PHP code to be executed (which, of course, it
> isn't).

That's right.

I'll try to elaborate and show some of the code, which might answer many
of the previous replies at the same time:

A typical webpage in this site uses embedded php to operate the hit
counter (PROCaddlog.php), pick up its headers (SCCSheaders.php) and pick
up its navigation table (SCCSnavtable.php).


~~~~~~~ Typical webpage ~~~~~~~~
<HTML>
<HEAD>
   <TITLE>Picture Gallery</TITLE>
<meta name="KEYWORDS" content="Coal Canal, Somersetshire Coal Canal,
Somerset Coal Canal, locks, caissons, Kennet & Avon,Weldon, Robert
Weldon, Caisoon Lock, Inclined plane, Combe Hay, Bath, Wellow, Weldon,
William Smith, Tuckingmill Tramway,  Dorset & Somerset Canal">
</HEAD>
<BODY BGCOLOR="#CCFFFF">
<CENTER><!--NOEDIT--><?php 
include($_SERVER['DOCUMENT_ROOT'] . "/PHP/counters/PROCaddlog.php"); 
addlog("Gallery");
include("http://www.coalcanal.org/PHP/SCCSheaders.php");
include("http://www.coalcanal.org/PHP/SCCSnavtable.php"); 
?><!--/NOEDIT-->

<P><FONT COLOR="#996633"><B>GALLERY</B></FONT>

<P>&nbsp;

<P><A HREF="http://www.flickr.com/photos/114362147@N06/">Photostream
on Flickr</A>

<P><A HREF="gallery/gallery-old.htm">Old pictures of the canal</A>

<P>&nbsp;

<P>&nbsp;

<P><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=5 WIDTH="100%">
   <TR>
      <TD>
         <P><A HREF="index.htm">Return to home page</A>
      </TD>
      <TD>
         <CENTER><A HREF="alphabetical.htm"><IMG SRC="images/Find.gif"
WIDTH=75 HEIGHT=26 BORDER=0 ALIGN=bottom></A></CENTER>
      </TD>
      <TD>
         <P ALIGN=right><A HREF="#TOP">Return to top of this page</A>
      </TD>
   </TR>
</TABLE>
</CENTER>
</BODY>
</HTML>

~~~~~~~~~~ End of Typical Webpage ~~~~~~~

The resulting output can be seen at:
<http://www.coalcanal.org/gallery.php>

I am now trying to build some password-protected pages and downloads,
where a link to a page or PDF file calls up a page delivery program
which decodes an encryped file and generates the PDF or page source code
on-the-fly.  The PDF-delivery program works fine, but when I use the
same code to deliver an HTML page, the php within the HTML appears as
text and fails to run.

~~~~~~~~~~ PDF Delivery Program ~~~~~~~~~~
<?php

$cookie1 = $_COOKIE["uservalid"];
stripslashes($cookie1);
setcookie ("uservalid", $cookie1 , time() + 900);
$cookie2 = strrev($cookie1);
$filename = $_GET["url"];
stripslashes($filename);
$text = "Empty string";

#Cookie check removed for security
#If ($cookie2~~~~~~~~~
        {
        ### Read file ###
        
        $filenamer = $filename . "r";   
                $fh = fopen($filenamer, 'r') or ("Downloader can't open
file $filenamer");
                        $text = fread($fh, filesize($filenamer));
                fclose($fh);
        
        
        ### Decode file ###
        
                # Decoding section removed for security#
        }

### Send file or refer to Login page ###

#Cookie check removed for security
#If ($cookie2~~~~~~~~~
        {
        header('Content-Type: application/octet-stream');
        header('Content-Disposition: attachment;
filename="'.basename($filename).'"');
        header('Content-Length: ' . filesize($filenamer));
        print $text;
        }
else
        {
        print "
        <HTML>
        <HEAD>
        </HEAD>
        <BODY BGCOLOR='#FFFFFF'>
        <CENTER><BR><BR>
        <FORM ACTION=\"Login2.php\" METHOD=POST>
        <P>Please <INPUT TYPE=submit NAME=Submit VALUE=\"Log in\">if you
want to download this file
        <P> <A
HREF='http://www.coalcanal.org.uk/contactform1.php'>Contact the
webmaster</A> if you continue to have difficulties</CENTER>
        </BODY>
        </HTML>
        ";
        }

?>

~~~~~~~~~~~~ End of PDF Delivery Program ~~~~~~~~~

As suggested by one of the replies, I am currently using a modification
of the above program to deliver webpages, whereby the 'include' is
processed by the delivery program (not by the HTML page) and the result
delivered to the HTML page at the appropriate point in the generated
source code.  

I wondered if there was a command which I could embed instead of the
"print $text;", which would cause the resulting HTML to be processed
like a normal webpage, so that the php within it would also run?



-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12773

In article
<1lgwd91.6d77v31qehadcN%adrian@poppyrecords.invalid.invalid>, Adrian
Tuddenham <adrian@poppyrecords.invalid.invalid> wrote:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:

> >  From what I can gather, he's generating a page which contains PHP code
> > from another PHP script, and sending the generated page to the browser -
> > expecting the generated PHP code to be executed (which, of course, it
> > isn't).
> 
> That's right.
> 
> I'll try to elaborate and show some of the code, which might answer many
> of the previous replies at the same time:
> 
> A typical webpage in this site uses embedded php to operate the hit
> counter (PROCaddlog.php), pick up its headers (SCCSheaders.php) and pick
> up its navigation table (SCCSnavtable.php).

You should really put a doctype here:

<!DOCTYPE html>

> <HTML>

at the top of your html so that the browser doesn't operate in quirks
mode (q.v.).

> <HEAD>
>    <TITLE>Picture Gallery</TITLE>
> <meta name="KEYWORDS" content="Coal Canal, Somersetshire Coal Canal,
> Somerset Coal Canal, locks, caissons, Kennet & Avon,Weldon, Robert
> Weldon, Caisoon Lock, Inclined plane, Combe Hay, Bath, Wellow, Weldon,
> William Smith, Tuckingmill Tramway,  Dorset & Somerset Canal">
> </HEAD>
> <BODY BGCOLOR="#CCFFFF">
> <CENTER><!--NOEDIT--><?php 
> include($_SERVER['DOCUMENT_ROOT'] . "/PHP/counters/PROCaddlog.php"); 
> addlog("Gallery");
> include("http://www.coalcanal.org/PHP/SCCSheaders.php");
> include("http://www.coalcanal.org/PHP/SCCSnavtable.php"); 
> ?><!--/NOEDIT-->
> 
> <P><FONT COLOR="#996633"><B>GALLERY</B></FONT>
> 
> <P>&nbsp;
> 
> <P><A HREF="http://www.flickr.com/photos/114362147@N06/">Photostream
> on Flickr</A>
> 
> <P><A HREF="gallery/gallery-old.htm">Old pictures of the canal</A>
> 
> <P>&nbsp;
> 
> <P>&nbsp;
> 
> <P><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=5 WIDTH="100%">
>    <TR>
>       <TD>
>          <P><A HREF="index.htm">Return to home page</A>
>       </TD>
>       <TD>
>          <CENTER><A HREF="alphabetical.htm"><IMG SRC="images/Find.gif"
> WIDTH=75 HEIGHT=26 BORDER=0 ALIGN=bottom></A></CENTER>
>       </TD>
>       <TD>
>          <P ALIGN=right><A HREF="#TOP">Return to top of this page</A>
>       </TD>
>    </TR>
> </TABLE>
> </CENTER>
> </BODY>
> </HTML>
> 
> ~~~~~~~~~~ End of Typical Webpage ~~~~~~~
> 
> The resulting output can be seen at:
> <http://www.coalcanal.org/gallery.php>
> 
> I am now trying to build some password-protected pages and downloads,
> where a link to a page or PDF file calls up a page delivery program
> which decodes an encryped file and generates the PDF or page source code
> on-the-fly.  The PDF-delivery program works fine, but when I use the
> same code to deliver an HTML page, the php within the HTML appears as
> text and fails to run.
> 
> ~~~~~~~~~~ PDF Delivery Program ~~~~~~~~~~
> <?php
> 
> $cookie1 = $_COOKIE["uservalid"];
> stripslashes($cookie1);

This ...

> setcookie ("uservalid", $cookie1 , time() + 900);
> $cookie2 = strrev($cookie1);
> $filename = $_GET["url"];
> stripslashes($filename);

... and this are surely no-ops as you don't assign the output of
stripslashes (q.v.) to anything.

> $text = "Empty string";
> 
> #Cookie check removed for security
> #If ($cookie2~~~~~~~~~
>         {
>         ### Read file ###
>         
>         $filenamer = $filename . "r";   
>                 $fh = fopen($filenamer, 'r') or ("Downloader can't open
> file $filenamer");
>                         $text = fread($fh, filesize($filenamer));
>                 fclose($fh);
>         
>         
>         ### Decode file ###
>         
>                 # Decoding section removed for security#
>         }
> 
> ### Send file or refer to Login page ###
> 
> #Cookie check removed for security
> #If ($cookie2~~~~~~~~~
>         {
>         header('Content-Type: application/octet-stream');
>         header('Content-Disposition: attachment;
> filename="'.basename($filename).'"');
>         header('Content-Length: ' . filesize($filenamer));
>         print $text;
>         }
> else
>         {
>         print "
>         <HTML>
>         <HEAD>
>         </HEAD>
>         <BODY BGCOLOR='#FFFFFF'>
>         <CENTER><BR><BR>
>         <FORM ACTION=\"Login2.php\" METHOD=POST>
>         <P>Please <INPUT TYPE=submit NAME=Submit VALUE=\"Log in\">if you
> want to download this file
>         <P> <A
> HREF='http://www.coalcanal.org.uk/contactform1.php'>Contact the
> webmaster</A> if you continue to have difficulties</CENTER>
>         </BODY>
>         </HTML>
>         ";
>         }
> 
> ?>
> 
> ~~~~~~~~~~~~ End of PDF Delivery Program ~~~~~~~~~
> 
> As suggested by one of the replies, I am currently using a modification
> of the above program to deliver webpages, whereby the 'include' is
> processed by the delivery program (not by the HTML page)

The include is *always* processed by PHP - see:

http://uk3.php.net/manual/en/function.include.php

> and the result delivered to the HTML page at the
> appropriate point in the generated source code.
> 
> I wondered if there was a command which I could embed instead of the
> "print $text;", which would cause the resulting HTML to be processed
> like a normal webpage, so that the php within it would also run?

Well, include might do it, I suppose. On first reading of the include
ref I gave above, I assumed that include's argument had always to be a
specific file, but there seem to be some hints in the user examples
that imply you could do:

  include $filenamer;

instead of

  print $text;

but I've never tried this myself.

BTW I've read that google etc ignore <meta keywords...> these days but
that's another story.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

[toc] | [prev] | [next] | [standalone]

#12774

Tim Streater <timstreater@greenbee.net> wrote:

[...]
> > I wondered if there was a command which I could embed instead of the
> > "print $text;", which would cause the resulting HTML to be processed
> > like a normal webpage, so that the php within it would also run?
> 
> Well, include might do it, I suppose. On first reading of the include
> ref I gave above, I assumed that include's argument had always to be a
> specific file, but there seem to be some hints in the user examples
> that imply you could do:
> 
>   include $filenamer;
> 
> instead of
> 
>   print $text;
> 
> but I've never tried this myself.

I had already tried it and it didn't work.    :-(

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12777

In article
<1lgwk0i.o5j5ms19glf6kN%adrian@poppyrecords.invalid.invalid>, Adrian
Tuddenham <adrian@poppyrecords.invalid.invalid> wrote:

> Tim Streater <timstreater@greenbee.net> wrote:
> 
> [...]
> > > I wondered if there was a command which I could embed instead of the
> > > "print $text;", which would cause the resulting HTML to be processed
> > > like a normal webpage, so that the php within it would also run?
> > 
> > Well, include might do it, I suppose. On first reading of the include
> > ref I gave above, I assumed that include's argument had always to be a
> > specific file, but there seem to be some hints in the user examples
> > that imply you could do:
> > 
> >   include $filenamer;
> > 
> > instead of
> > 
> >   print $text;
> > 
> > but I've never tried this myself.
> 
> I had already tried it and it didn't work.    :-(

Then either the file has to be in a specific place, or you can write
$text out to a /tmp file with a specific name and use that with the
include.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#12779

Tim Streater wrote:

> In article
> <1lgwk0i.o5j5ms19glf6kN%adrian@poppyrecords.invalid.invalid>, Adrian
> Tuddenham <adrian@poppyrecords.invalid.invalid> wrote:
> 
>> Tim Streater <timstreater@greenbee.net> wrote:
>>
>> [...]
>> > > I wondered if there was a command which I could embed instead of the
>> > > "print $text;", which would cause the resulting HTML to be processed
>> > > like a normal webpage, so that the php within it would also run?
>> > > Well, include might do it, I suppose. On first reading of the include
>> > ref I gave above, I assumed that include's argument had always to be a
>> > specific file, but there seem to be some hints in the user examples
>> > that imply you could do:
>> > >   include $filenamer;
>> > > instead of
>> > >   print $text;
>> > > but I've never tried this myself.
>>
>> I had already tried it and it didn't work.    :-(
> 
> Then either the file has to be in a specific place, or you can write
> $text out to a /tmp file with a specific name and use that with the
> include.

Or evaluate the generated PHP code with eval().  However, I suppose
there's a design mistake here.  Generating and executing PHP code on the
fly doesn't seem to be reasonable (at least for most purposes).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12784

On Tue, 11 Feb 2014 13:55:57 +0100, Christoph Michael Becker wrote:

> Or evaluate the generated PHP code with eval().  However, I suppose
> there's a design mistake here.  Generating and executing PHP code on the
> fly doesn't seem to be reasonable (at least for most purposes).

I'll second that. Instead of dynamically generating php code to generate 
html and inserting the dynamically generated php code into your file, you 
should refactor the script that produces the dynamic php to instead 
generate the resultant html that the dynamically generated php is 
expected to create, and arrange the code so that the html is just 
inserted at the appropriate place

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12789

Denis McMahon <denismfmcmahon@gmail.com> wrote:

> On Tue, 11 Feb 2014 13:55:57 +0100, Christoph Michael Becker wrote:
> 
> > Or evaluate the generated PHP code with eval().  However, I suppose
> > there's a design mistake here.  Generating and executing PHP code on the
> > fly doesn't seem to be reasonable (at least for most purposes).
> 
> I'll second that. Instead of dynamically generating php code to generate
> html and inserting the dynamically generated php code into your file, you
> should refactor the script that produces the dynamic php to instead 
> generate the resultant html that the dynamically generated php is 
> expected to create, and arrange the code so that the html is just 
> inserted at the appropriate place

That's what I've decided to do.  It just means that the protected pages
will have to have a different sort of 'include' command from the
unprotected ones.

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12798

On Tue, 11 Feb 2014 14:31:51 +0000, Adrian Tuddenham wrote:

> Denis McMahon <denismfmcmahon@gmail.com> wrote:
> 
>> On Tue, 11 Feb 2014 13:55:57 +0100, Christoph Michael Becker wrote:
>> 
>> > Or evaluate the generated PHP code with eval().  However, I suppose
>> > there's a design mistake here.  Generating and executing PHP code on
>> > the fly doesn't seem to be reasonable (at least for most purposes).
>> 
>> I'll second that. Instead of dynamically generating php code to
>> generate html and inserting the dynamically generated php code into
>> your file, you should refactor the script that produces the dynamic php
>> to instead generate the resultant html that the dynamically generated
>> php is expected to create, and arrange the code so that the html is
>> just inserted at the appropriate place
> 
> That's what I've decided to do.  It just means that the protected pages
> will have to have a different sort of 'include' command from the
> unprotected ones.

If you want to protect the included files from being accessed directly, 
move them outside of the webroot structure.

The web server can only "serve" files inside it's directory structure, 
but a php include can access any file according to file system access 
constraints, so you can even include a file from a directory on another 
computer as long as you specify the pathname correctly.

I always put files that include things like database access usernames and 
passwords outside of the webroot, that way no one can request 
"db_passwords.php" and get the mysql password and user that php is using.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12781

On 2/11/2014 5:11 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/10/2014 6:06 PM, Denis McMahon wrote:
>>> On Mon, 10 Feb 2014 21:44:02 +0000, Adrian Tuddenham wrote:
>>>
>>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 2/10/2014 3:24 PM, 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?
>>>
>>>>> The PHP code in your generated file is only executed when the file is
>>>>> processed as a web page.  This is done by the web server, based on the
>>>>> file extension (default is .php; you do have that as the file
>>>>> extension,
>>>>> right?).
>>>
>>>> Yes -  and the same code runs perfectly well with all its headers if the
>>>> file is sitting on the server and I call it up with a browser.  It is
>>>> only if I 'create' it on the fly from a php program that it doesn't work
>>>> - the HTML runs but the php doesn't.
>>>
>>> What happens is that php script is executed by a script processor in the
>>> server, and the output of the php script is delivered by the server as
>>> html.
>>>
>>>>> Any other means of downloading the file (i.e. ftp) will not cause the
>>>>> PHP code to be executed.
>>>
>>>> I was using a browser to view it, but the source code was coming from a
>>>> php program, not directly from a file on the server.
>>>
>>> When you say "the source code was coming from a php program" do you mean
>>> that you were viewing a php script with a web browser, or do you mean
>>> that you were running a script through a php interpreter and viewing the
>>> output?
>>>
>>> Any php processing for web pages that is needed is generally carried out
>>> in a process called from the main server process in the web server.
>>> Normally when a .php file is requested, the webserver passes the file to
>>> the php processor, and takes the output of the php processor and sends
>>> that to the requesting client as html (unless another content type is
>>> specified).
>>>
>>> It's also possible for php to be embedded in html files, in which case
>>> the same thing happens for html files.
>>>
>>> I can't quite map your description of what you're doing and what you seem
>>> to expect with my knowledge of how web servers work, this suggests that
>>> either you're using the terminology in a way that I don't understand, or
>>> possibly that your perception of what is happening is not what is
>>> actually happening.
>>>
>>
>> Denis,
>>
>>   From what I can gather, he's generating a page which contains PHP code
>> from another PHP script, and sending the generated page to the browser -
>> expecting the generated PHP code to be executed (which, of course, it
>> isn't).
>
> That's right.
>

Then no, anything generated by your code is NOT processed by the 
interpreter.  It is simply sent to the client.

> I'll try to elaborate and show some of the code, which might answer many
> of the previous replies at the same time:
>
> A typical webpage in this site uses embedded php to operate the hit
> counter (PROCaddlog.php), pick up its headers (SCCSheaders.php) and pick
> up its navigation table (SCCSnavtable.php).
>
>
> ~~~~~~~ Typical webpage ~~~~~~~~
> <HTML>
> <HEAD>
>     <TITLE>Picture Gallery</TITLE>
> <meta name="KEYWORDS" content="Coal Canal, Somersetshire Coal Canal,
> Somerset Coal Canal, locks, caissons, Kennet & Avon,Weldon, Robert
> Weldon, Caisoon Lock, Inclined plane, Combe Hay, Bath, Wellow, Weldon,
> William Smith, Tuckingmill Tramway,  Dorset & Somerset Canal">
> </HEAD>
> <BODY BGCOLOR="#CCFFFF">
> <CENTER><!--NOEDIT--><?php
> include($_SERVER['DOCUMENT_ROOT'] . "/PHP/counters/PROCaddlog.php");
> addlog("Gallery");
> include("http://www.coalcanal.org/PHP/SCCSheaders.php");
> include("http://www.coalcanal.org/PHP/SCCSnavtable.php");
> ?><!--/NOEDIT-->
>
> <P><FONT COLOR="#996633"><B>GALLERY</B></FONT>
>
> <P>&nbsp;
>
> <P><A HREF="http://www.flickr.com/photos/114362147@N06/">Photostream
> on Flickr</A>
>
> <P><A HREF="gallery/gallery-old.htm">Old pictures of the canal</A>
>
> <P>&nbsp;
>
> <P>&nbsp;
>
> <P><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=5 WIDTH="100%">
>     <TR>
>        <TD>
>           <P><A HREF="index.htm">Return to home page</A>
>        </TD>
>        <TD>
>           <CENTER><A HREF="alphabetical.htm"><IMG SRC="images/Find.gif"
> WIDTH=75 HEIGHT=26 BORDER=0 ALIGN=bottom></A></CENTER>
>        </TD>
>        <TD>
>           <P ALIGN=right><A HREF="#TOP">Return to top of this page</A>
>        </TD>
>     </TR>
> </TABLE>
> </CENTER>
> </BODY>
> </HTML>
>
> ~~~~~~~~~~ End of Typical Webpage ~~~~~~~
>
> The resulting output can be seen at:
> <http://www.coalcanal.org/gallery.php>
>

Is this supposed to be the page your code has generated?  Or is this a 
file on your site?  The code here is being processed.

> I am now trying to build some password-protected pages and downloads,
> where a link to a page or PDF file calls up a page delivery program
> which decodes an encryped file and generates the PDF or page source code
> on-the-fly.  The PDF-delivery program works fine, but when I use the
> same code to deliver an HTML page, the php within the HTML appears as
> text and fails to run.
>

It won't work.

> ~~~~~~~~~~ PDF Delivery Program ~~~~~~~~~~
> <?php
>
> $cookie1 = $_COOKIE["uservalid"];
> stripslashes($cookie1);
> setcookie ("uservalid", $cookie1 , time() + 900);
> $cookie2 = strrev($cookie1);
> $filename = $_GET["url"];
> stripslashes($filename);
> $text = "Empty string";
>
> #Cookie check removed for security
> #If ($cookie2~~~~~~~~~
>          {
>          ### Read file ###
>
>          $filenamer = $filename . "r";
>                  $fh = fopen($filenamer, 'r') or ("Downloader can't open
> file $filenamer");
>                          $text = fread($fh, filesize($filenamer));
>                  fclose($fh);
>
>
>          ### Decode file ###
>
>                  # Decoding section removed for security#
>          }
>
> ### Send file or refer to Login page ###
>
> #Cookie check removed for security
> #If ($cookie2~~~~~~~~~
>          {
>          header('Content-Type: application/octet-stream');
>          header('Content-Disposition: attachment;
> filename="'.basename($filename).'"');
>          header('Content-Length: ' . filesize($filenamer));
>          print $text;
>          }
> else
>          {
>          print "
>          <HTML>
>          <HEAD>
>          </HEAD>
>          <BODY BGCOLOR='#FFFFFF'>
>          <CENTER><BR><BR>
>          <FORM ACTION=\"Login2.php\" METHOD=POST>
>          <P>Please <INPUT TYPE=submit NAME=Submit VALUE=\"Log in\">if you
> want to download this file
>          <P> <A
> HREF='http://www.coalcanal.org.uk/contactform1.php'>Contact the
> webmaster</A> if you continue to have difficulties</CENTER>
>          </BODY>
>          </HTML>
>          ";
>          }
>
> ?>
>
> ~~~~~~~~~~~~ End of PDF Delivery Program ~~~~~~~~~
>
> As suggested by one of the replies, I am currently using a modification
> of the above program to deliver webpages, whereby the 'include' is
> processed by the delivery program (not by the HTML page) and the result
> delivered to the HTML page at the appropriate point in the generated
> source code.
>
> I wondered if there was a command which I could embed instead of the
> "print $text;", which would cause the resulting HTML to be processed
> like a normal webpage, so that the php within it would also run?
>
>
>

You could use eval(), if your host allows it.  But that is a huge 
security risk.  You're just asking to be hacked.

My main question here would be - what are you trying to accomplish by 
having files encrypted on your server.  Since the decryption code is 
right in plain sight, encrypting the files adds no security.  If they 
can get to your raw files, they can get to your decryption code.

And in any case, the decrypted page (along with images, etc.) is 
available at the browser just as soon as someone requests it.

I think your whole approach needs rethinking.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12788

Jerry Stuckle <jstucklex@attglobal.net> wrote:

[...] 
> My main question here would be - what are you trying to accomplish by
> having files encrypted on your server.  Since the decryption code is 
> right in plain sight, encrypting the files adds no security.  If they
> can get to your raw files, they can get to your decryption code.

I'm not trying to produce a high-security system, just something which
deters the casual user from downloading PDFs that members of the group
have paid their membership fee to receive.  I doubt if anyone wants to
go to all the trouble of decrypting a PDF file in order to avoid paying
£7.50

I am a bit worried by your statement that the decryption code is in
plain sight, how can that be protected better than it already is?  The
filename in the GET of the link url is also encrypted (very crudely) so,
although it is in plain view, it wouldn't lead the hacker directly to
the encrypted PDF file.

> 
> And in any case, the decrypted page (along with images, etc.) is 
> available at the browser just as soon as someone requests it.

That 'someone' would have to be a member and they could equally well
send their password to a friend.  There is a download log which should
alert me if something untoward is happening through the password system.


> I think your whole approach needs rethinking.

I agree it isn't suitable for a high security website, it is just making
the best of a "Topsy".


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12791

On 2/11/2014 9:31 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
> [...]
>> My main question here would be - what are you trying to accomplish by
>> having files encrypted on your server.  Since the decryption code is
>> right in plain sight, encrypting the files adds no security.  If they
>> can get to your raw files, they can get to your decryption code.
>
> I'm not trying to produce a high-security system, just something which
> deters the casual user from downloading PDFs that members of the group
> have paid their membership fee to receive.  I doubt if anyone wants to
> go to all the trouble of decrypting a PDF file in order to avoid paying
> £7.50
>

First of all, you don't need to go to all the trouble of encrypting a 
pdf to make it unavailable to the casual user.  Just place the file 
outside of your document_root hierarchy and download it with PHP.

Second, it's still no security.  Once someone has the pdf, they can make 
and send all the copies they want.

> I am a bit worried by your statement that the decryption code is in
> plain sight, how can that be protected better than it already is?  The
> filename in the GET of the link url is also encrypted (very crudely) so,
> although it is in plain view, it wouldn't lead the hacker directly to
> the encrypted PDF file.
>

That's correct.  Anyone who can access your source files can see the 
decryption code.

What you have is security by obfuscation - which is only the illusion of 
security.  And you're going to a whole lot of unnecessary work to get it.

>>
>> And in any case, the decrypted page (along with images, etc.) is
>> available at the browser just as soon as someone requests it.
>
> That 'someone' would have to be a member and they could equally well
> send their password to a friend.  There is a download log which should
> alert me if something untoward is happening through the password system.
>

But if they send the file to their pals (or post it on another website), 
you would never know.

>
>> I think your whole approach needs rethinking.
>
> I agree it isn't suitable for a high security website, it is just making
> the best of a "Topsy".
>
>

It's not even suitable for a low security website.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12794

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/11/2014 9:31 AM, Adrian Tuddenham wrote:
> > Jerry Stuckle <jstucklex@attglobal.net> wrote:
> >
> > [...]
> >> My main question here would be - what are you trying to accomplish by
> >> having files encrypted on your server.  Since the decryption code is
> >> right in plain sight, encrypting the files adds no security.  If they
> >> can get to your raw files, they can get to your decryption code.
> >
> > I'm not trying to produce a high-security system, just something which
> > deters the casual user from downloading PDFs that members of the group
> > have paid their membership fee to receive.  I doubt if anyone wants to
> > go to all the trouble of decrypting a PDF file in order to avoid paying
> > £7.50
> >
> 
> First of all, you don't need to go to all the trouble of encrypting a
> pdf to make it unavailable to the casual user.  Just place the file 
> outside of your document_root hierarchy and download it with PHP.

I have no access to the server outside my own directory.


> Second, it's still no security.  Once someone has the pdf, they can make
> and send all the copies they want.

That is why I said it is only a deterrent.  Members who receive the
printed copy can photocopy it and send it to their friends - or even
scan it in and distribute their own PDF of it.

>>I am a bit worried by your statement that the decryption code is in
>>plain sight,

> That's correct.  Anyone who can access your source files can see the 
> decryption code.

How would they get access the source files?  I thought the server
blocked that sort of thing.

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12796

On 2/11/2014 10:31 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/11/2014 9:31 AM, Adrian Tuddenham wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>
>>> [...]
>>>> My main question here would be - what are you trying to accomplish by
>>>> having files encrypted on your server.  Since the decryption code is
>>>> right in plain sight, encrypting the files adds no security.  If they
>>>> can get to your raw files, they can get to your decryption code.
>>>
>>> I'm not trying to produce a high-security system, just something which
>>> deters the casual user from downloading PDFs that members of the group
>>> have paid their membership fee to receive.  I doubt if anyone wants to
>>> go to all the trouble of decrypting a PDF file in order to avoid paying
>>> £7.50
>>>
>>
>> First of all, you don't need to go to all the trouble of encrypting a
>> pdf to make it unavailable to the casual user.  Just place the file
>> outside of your document_root hierarchy and download it with PHP.
>
> I have no access to the server outside my own directory.
>

Then I would suggest you change hosting companies.  Any decent hosting 
company will give you access to one level below your web root directory. 
  I wouldn't host with one which does not.
>
>> Second, it's still no security.  Once someone has the pdf, they can make
>> and send all the copies they want.
>
> That is why I said it is only a deterrent.  Members who receive the
> printed copy can photocopy it and send it to their friends - or even
> scan it in and distribute their own PDF of it.
>

No, it's not even a deterrent.  It's only the illusion of one.

>>> I am a bit worried by your statement that the decryption code is in
>>> plain sight,
>
>> That's correct.  Anyone who can access your source files can see the
>> decryption code.
>
> How would they get access the source files?  I thought the server
> blocked that sort of thing.
>

If everything is working correctly, and hackers don't get into the 
server.  But this also includes potentially other websites on the same 
server, for instance, if the server isn't properly secured, as well as 
anyone who has direct access to the server itself.

Personally, if your hosting company don't even give you access to a 
directory below your document root, I wouldn't be trusting them to 
properly secure the server, either (that doesn't necessarily mean they 
DO secure the server if they give you this access - it's just more 
LIKELY they know what they're doing).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12804

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/11/2014 10:31 AM, Adrian Tuddenham wrote:
> > Jerry Stuckle <jstucklex@attglobal.net> wrote:
> >
> >> On 2/11/2014 9:31 AM, Adrian Tuddenham wrote:
> >>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> >>>
> >>> [...]
> >>>> My main question here would be - what are you trying to accomplish by
> >>>> having files encrypted on your server.  Since the decryption code is
> >>>> right in plain sight, encrypting the files adds no security.  If they
> >>>> can get to your raw files, they can get to your decryption code.
> >>>
> >>> I'm not trying to produce a high-security system, just something which
> >>> deters the casual user from downloading PDFs that members of the group
> >>> have paid their membership fee to receive.  I doubt if anyone wants to
> >>> go to all the trouble of decrypting a PDF file in order to avoid paying
> >>> £7.50
> >>>
> >>
> >> First of all, you don't need to go to all the trouble of encrypting a
> >> pdf to make it unavailable to the casual user.  Just place the file
> >> outside of your document_root hierarchy and download it with PHP.
> >
> > I have no access to the server outside my own directory.
> >
> 
> Then I would suggest you change hosting companies.  Any decent hosting
> company will give you access to one level below your web root directory.
>   I wouldn't host with one which does not.

I may have unintentionally misled you because of my ignorance of server
terminology.  I might be able to do what you suggest, but I have no idea
how to do it.   I presume that raises questions outside the the scope of
a php newsgroup and is something I should folow up separately.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#12807

On 2/12/2014 5:13 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/11/2014 10:31 AM, Adrian Tuddenham wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/11/2014 9:31 AM, Adrian Tuddenham wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>>>
>>>>> [...]
>>>>>> My main question here would be - what are you trying to accomplish by
>>>>>> having files encrypted on your server.  Since the decryption code is
>>>>>> right in plain sight, encrypting the files adds no security.  If they
>>>>>> can get to your raw files, they can get to your decryption code.
>>>>>
>>>>> I'm not trying to produce a high-security system, just something which
>>>>> deters the casual user from downloading PDFs that members of the group
>>>>> have paid their membership fee to receive.  I doubt if anyone wants to
>>>>> go to all the trouble of decrypting a PDF file in order to avoid paying
>>>>> £7.50
>>>>>
>>>>
>>>> First of all, you don't need to go to all the trouble of encrypting a
>>>> pdf to make it unavailable to the casual user.  Just place the file
>>>> outside of your document_root hierarchy and download it with PHP.
>>>
>>> I have no access to the server outside my own directory.
>>>
>>
>> Then I would suggest you change hosting companies.  Any decent hosting
>> company will give you access to one level below your web root directory.
>>    I wouldn't host with one which does not.
>
> I may have unintentionally misled you because of my ignorance of server
> terminology.  I might be able to do what you suggest, but I have no idea
> how to do it.   I presume that raises questions outside the the scope of
> a php newsgroup and is something I should folow up separately.
>
>

Yes, it's out of the range of this newsgroup.  However, it's an 
important feature any time you need to control access to files.

And yes, there are some companies out there which don't allow access 
outside of the document root.  I would not host with any of these companies.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12792

adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) writes:
<snip>
> I'm not trying to produce a high-security system, just something which
> deters the casual user from downloading PDFs that members of the group
> have paid their membership fee to receive.  I doubt if anyone wants to
> go to all the trouble of decrypting a PDF file in order to avoid paying
> £7.50

I missed your explanation of what you were doing.  It was a bit buried.
Sorry about that.

User must authenticate n some way, yes?  Having done that, they can get
one or more documents that they have paid for?  They get send the
documents "in the clear", yes?

If that's the application, I can't see how you got to where you are.
The documents can (usually) be put somewhere where PHP can see them, but
a browser can't.  A simple bit of PHP checks the credentials and
delivers that document.  I don't see any need for encrypting the PDFs or
generating PHP to be executed.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12790

adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) writes:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
<snip>
>>  From what I can gather, he's generating a page which contains PHP code
>> from another PHP script, and sending the generated page to the browser -
>> expecting the generated PHP code to be executed (which, of course, it
>> isn't).
>
> That's right.

I'll second (third?, forth?) the question: what are trying to do that
has lead to this design?  It seems all wrong.

The only time I saw anything like it, the author was unaware that
functions can be created by PHP functions (though how well this works
depends on the version of PHP that you have).  It may be that your task
can be achieved with any special re-execution mechanism.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12793

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) writes:
> 
> > Jerry Stuckle <jstucklex@attglobal.net> wrote:
> <snip>
> >>  From what I can gather, he's generating a page which contains PHP code
> >> from another PHP script, and sending the generated page to the browser -
> >> expecting the generated PHP code to be executed (which, of course, it
> >> isn't).
> >
> > That's right.
> 
> I'll second (third?, forth?) the question: what are trying to do that
> has lead to this design?  It seems all wrong.
> 
> The only time I saw anything like it, the author was unaware that
> functions can be created by PHP functions (though how well this works
> depends on the version of PHP that you have).  It may be that your task
> can be achieved with any special re-execution mechanism.

I think this is running on some version php 4. 

I was not only unaware that functions could be created, but was
convinced by the results of several searches that they could not.  I was
probably searching for the wrong thing (until you know the answer, it is
not obvious how to ask the right question), so could you please tell me
what I should be looking for?


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web