I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's member
id from the session.
I have a very basic test script (test.php) which works fine when I access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers already sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The most
common advice is to search for blank space at the beginning or end of the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755. Still get
same error.
If it helps, here are the first few lines of my code: There is no space at
the top of my file.
#!/usr/local/bin/php
<?
session_start();
include "verify.inc";
?>
<html>
<head>
</head>
<body>
By the way, when I tried to delete the line between #!/usr/local/bin/php and
<?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
PHP ORDER API CGI SCRIPT
9 posts
• Page 1 of 1
Re: PHP ORDER API CGI SCRIPT
by Brandon Eley » Wed Jul 14, 2004 8:53 pm
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is a
completely different scripting language (though very similar) and thus
should not be named *.pl or *.cgi but only *.php, *.php4 or *.php3 (for
version numbers) or *.phtml (if your server is setup this way - rare
though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written in
perl, not PHP. Then you can name it .cgi or .pl and place it inside your
CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is a
completely different scripting language (though very similar) and thus
should not be named *.pl or *.cgi but only *.php, *.php4 or *.php3 (for
version numbers) or *.phtml (if your server is setup this way - rare
though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written in
perl, not PHP. Then you can name it .cgi or .pl and place it inside your
CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's member
id from the session.
I have a very basic test script (test.php) which works fine when I access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers already sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The most
common advice is to search for blank space at the beginning or end of the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755. Still get
same error.
If it helps, here are the first few lines of my code: There is no space at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between #!/usr/local/bin/php and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- Brandon Eley
Re: PHP ORDER API CGI SCRIPT
by tjmitoraj » Thu Jul 15, 2004 7:23 am
Brandon,
Your observations would definitely explain why I am having some problems.
I am a bit puzzled though because there are articles on the web, which
indicate that it is now possible to use PHP as a shell scripting language.
One article is found at
http://www.phpbuilder.com/columns/darrell20000319.php3
This article also suggests a solution to my situation. I have compiled my
PHP as an Apache module instead of a CGI binary. Apparently, I can have
both versions running on my server at the same time with no problems.
Since I am relatively new to PHP, but I am using it for the rest of my site,
and since I have no experience in Perl, I was hoping I could stick to PHP.
I'll have to research this further and make a decision on which scripting
language to use.
Another option I am considering is to use a Perl Script to simply pass the
purchase date to a php file, which will add the information into my
database.
It looks like I have some research to do!
Thanks.
Tom Mitoraj
"Brandon Eley" <brandon@2bigfeet.com> wrote in message
news:cd4v4c$d7m$1@eval.shopsite.com...
Your observations would definitely explain why I am having some problems.
I am a bit puzzled though because there are articles on the web, which
indicate that it is now possible to use PHP as a shell scripting language.
One article is found at
http://www.phpbuilder.com/columns/darrell20000319.php3
This article also suggests a solution to my situation. I have compiled my
PHP as an Apache module instead of a CGI binary. Apparently, I can have
both versions running on my server at the same time with no problems.
Since I am relatively new to PHP, but I am using it for the rest of my site,
and since I have no experience in Perl, I was hoping I could stick to PHP.
I'll have to research this further and make a decision on which scripting
language to use.
Another option I am considering is to use a Perl Script to simply pass the
purchase date to a php file, which will add the information into my
database.
It looks like I have some research to do!
Thanks.
Tom Mitoraj
"Brandon Eley" <brandon@2bigfeet.com> wrote in message
news:cd4v4c$d7m$1@eval.shopsite.com...
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is a
completely different scripting language (though very similar) and thus
should not be named *.pl or *.cgi but only *.php, *.php4 or *.php3 (for
version numbers) or *.phtml (if your server is setup this way - rare
though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written in
perl, not PHP. Then you can name it .cgi or .pl and place it inside your
CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's
member
id from the session.
I have a very basic test script (test.php) which works fine when I
access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to test.cgi
and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers already
sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The
most
common advice is to search for blank space at the beginning or end of
the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755. Still
get
same error.
If it helps, here are the first few lines of my code: There is no space
at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between #!/usr/local/bin/php
and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- tjmitoraj
Re: PHP ORDER API CGI SCRIPT
by loren_d_c » Thu Jul 15, 2004 9:49 am
PHP can be used as a shell scripting language like Perl, however it is
not compiled that way by default on most systems.
On UNIX systems it does not matter if an executable is named .cgi, .pl,
..php, or whatever. If the file is executable and is in a directory where
direct execution is allow (for example, in a cgi-bin directory or in the
ShopSite cgi directories), the system will check to see if it is a
binary file or a text file. If it is a binary file, if will try to
execute it directly, if it is a text file is will look for the
#!/path/to/shell/interpreter line on the first line of the file. So in
theory you can have a PHP script executed that way (#!/usr/bin/php, or
whatever), however unless you specifically know that PHP interpreter
binary was compiled to allow CGI-type execution, you can almost bet that
it was not.
When accessing PHP files directly (by URL), then they do need to be
named .php (or .php3, or .phtml), because in that case the webserver is
loading them through it's PHP module, so it needs to see those
extensions. PHP files accessed this way do not need the execute
permission bit set, but ones that are run as CGI's (see paragraph above) do.
-Loren
Brandon Eley wrote:
not compiled that way by default on most systems.
On UNIX systems it does not matter if an executable is named .cgi, .pl,
..php, or whatever. If the file is executable and is in a directory where
direct execution is allow (for example, in a cgi-bin directory or in the
ShopSite cgi directories), the system will check to see if it is a
binary file or a text file. If it is a binary file, if will try to
execute it directly, if it is a text file is will look for the
#!/path/to/shell/interpreter line on the first line of the file. So in
theory you can have a PHP script executed that way (#!/usr/bin/php, or
whatever), however unless you specifically know that PHP interpreter
binary was compiled to allow CGI-type execution, you can almost bet that
it was not.
When accessing PHP files directly (by URL), then they do need to be
named .php (or .php3, or .phtml), because in that case the webserver is
loading them through it's PHP module, so it needs to see those
extensions. PHP files accessed this way do not need the execute
permission bit set, but ones that are run as CGI's (see paragraph above) do.
-Loren
Brandon Eley wrote:
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is a
completely different scripting language (though very similar) and thus
should not be named *.pl or *.cgi but only *.php, *.php4 or *.php3 (for
version numbers) or *.phtml (if your server is setup this way - rare
though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written in
perl, not PHP. Then you can name it .cgi or .pl and place it inside your
CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's
member
id from the session.
I have a very basic test script (test.php) which works fine when I
access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to
test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers already
sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The most
common advice is to search for blank space at the beginning or end of the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755.
Still get
same error.
If it helps, here are the first few lines of my code: There is no
space at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between
#!/usr/local/bin/php and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- loren_d_c
- Posts: 2571
- Joined: Fri Aug 04, 2006 12:02 pm
- Location: Anywhere
Re: PHP ORDER API CGI SCRIPT
by Brandon Eley » Wed Jul 21, 2004 1:38 pm
It's probably a good idea just out of practice (and easy updating) to
name files according to what they do. Naming a php file *.pl or *.cgi
just seems confusing especially if you are not the only person that will
ever work on the site...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
Loren wrote:
name files according to what they do. Naming a php file *.pl or *.cgi
just seems confusing especially if you are not the only person that will
ever work on the site...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
Loren wrote:
PHP can be used as a shell scripting language like Perl, however it is
not compiled that way by default on most systems.
On UNIX systems it does not matter if an executable is named .cgi, .pl,
.php, or whatever. If the file is executable and is in a directory where
direct execution is allow (for example, in a cgi-bin directory or in the
ShopSite cgi directories), the system will check to see if it is a
binary file or a text file. If it is a binary file, if will try to
execute it directly, if it is a text file is will look for the
#!/path/to/shell/interpreter line on the first line of the file. So in
theory you can have a PHP script executed that way (#!/usr/bin/php, or
whatever), however unless you specifically know that PHP interpreter
binary was compiled to allow CGI-type execution, you can almost bet that
it was not.
When accessing PHP files directly (by URL), then they do need to be
named .php (or .php3, or .phtml), because in that case the webserver is
loading them through it's PHP module, so it needs to see those
extensions. PHP files accessed this way do not need the execute
permission bit set, but ones that are run as CGI's (see paragraph above)
do.
-Loren
Brandon Eley wrote:
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is
a completely different scripting language (though very similar) and
thus should not be named *.pl or *.cgi but only *.php, *.php4 or
*.php3 (for version numbers) or *.phtml (if your server is setup this
way - rare though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written
in perl, not PHP. Then you can name it .cgi or .pl and place it inside
your CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's
member
id from the session.
I have a very basic test script (test.php) which works fine when I
access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to
test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers
already sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The
most
common advice is to search for blank space at the beginning or end of
the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755.
Still get
same error.
If it helps, here are the first few lines of my code: There is no
space at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between
#!/usr/local/bin/php and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- Brandon Eley
Re: PHP ORDER API CGI SCRIPT
by tjmitoraj » Tue Jul 27, 2004 6:31 am
Gentlemen,
First, I appreciate your comments.
I have successfully tested a PHP style CGI and called it from the Shopsite
Order API folder.
I have encountered another hurdle and I have found a workaround, but I am
not sure if this is such a good idea!
Essentially, my Session Variables are lost when my script is called
automatically from Shopsite. I have done lots of research on this and see
it is a problem, which other people have faced. In case you are wondering,
I am calling the start_session() function at the top of my script. The
problem is when I check the session id, it is a completely new session and
none of the session variables contain the data I defined when the user
logged into my site.
One possible reason for this issue is reported in the following link -
http://support.microsoft.com/default.as ... -us;316112
and summarized here - "Security patch MS01-055 prevents servers with
improper name syntax from setting cookies names. Domains that use cookies
must use only alphanumeric characters ("-" or ".") in the domain name and
the server name. Internet Explorer blocks cookies from a server if the
server name contains other characters, such as an underscore character
("_")." Since there are lots of strange characters in some of the
Shopsite generated pages, I am not sure if this is contributing to the
problem or if the automatic order API call somehow trashes the session.
My initial workaround - I capture the users IP address when they log into my
site and then store it in my database. When the user executes an order
through Shopsite, I have my script capture the IP address again, look
through the user table in my database for a matching IP. I then lookup the
associated user. This allows me to take the Shopsite purchase data for that
user and update the other tables, pages, etc. in my database.
I suspect that this is not the best solution and have the following
questions:
- Is it secure?
- Does a user's IP address ever change in the middle of a connection?
- If the connection drops for some reason and they reconnect, does the IP
address typically change? I understand some ISPs dynamically assign them,
so this might be a problem.
- Would it be feasible to add error trapping code in my script so a changed
IP address is detected (when it sees that there is no matching IP) and the
customer/webmaster is then notified that the necessary updates will have to
be processed manually? It will be a minor inconvenience, but not too bad if
it doesn't happen regularly. This manual processing will be necessary since
the purchase was completed prior to the cgi call.
If this is not a feasible option and I can't figure out how to get the
sessions working, I might have to log in again after they make the purchase
(but that wouldn't be a very user friendly option, of course).
Any advice you can provide would be appreciated!
Thank you.
Tom Mitoraj
"Brandon Eley" <brandon@2bigfeet.com> wrote in message
news:cdmk9e$j1g$2@eval.shopsite.com...
First, I appreciate your comments.
I have successfully tested a PHP style CGI and called it from the Shopsite
Order API folder.
I have encountered another hurdle and I have found a workaround, but I am
not sure if this is such a good idea!
Essentially, my Session Variables are lost when my script is called
automatically from Shopsite. I have done lots of research on this and see
it is a problem, which other people have faced. In case you are wondering,
I am calling the start_session() function at the top of my script. The
problem is when I check the session id, it is a completely new session and
none of the session variables contain the data I defined when the user
logged into my site.
One possible reason for this issue is reported in the following link -
http://support.microsoft.com/default.as ... -us;316112
and summarized here - "Security patch MS01-055 prevents servers with
improper name syntax from setting cookies names. Domains that use cookies
must use only alphanumeric characters ("-" or ".") in the domain name and
the server name. Internet Explorer blocks cookies from a server if the
server name contains other characters, such as an underscore character
("_")." Since there are lots of strange characters in some of the
Shopsite generated pages, I am not sure if this is contributing to the
problem or if the automatic order API call somehow trashes the session.
My initial workaround - I capture the users IP address when they log into my
site and then store it in my database. When the user executes an order
through Shopsite, I have my script capture the IP address again, look
through the user table in my database for a matching IP. I then lookup the
associated user. This allows me to take the Shopsite purchase data for that
user and update the other tables, pages, etc. in my database.
I suspect that this is not the best solution and have the following
questions:
- Is it secure?
- Does a user's IP address ever change in the middle of a connection?
- If the connection drops for some reason and they reconnect, does the IP
address typically change? I understand some ISPs dynamically assign them,
so this might be a problem.
- Would it be feasible to add error trapping code in my script so a changed
IP address is detected (when it sees that there is no matching IP) and the
customer/webmaster is then notified that the necessary updates will have to
be processed manually? It will be a minor inconvenience, but not too bad if
it doesn't happen regularly. This manual processing will be necessary since
the purchase was completed prior to the cgi call.
If this is not a feasible option and I can't figure out how to get the
sessions working, I might have to log in again after they make the purchase
(but that wouldn't be a very user friendly option, of course).
Any advice you can provide would be appreciated!
Thank you.
Tom Mitoraj
"Brandon Eley" <brandon@2bigfeet.com> wrote in message
news:cdmk9e$j1g$2@eval.shopsite.com...
It's probably a good idea just out of practice (and easy updating) to
name files according to what they do. Naming a php file *.pl or *.cgi
just seems confusing especially if you are not the only person that will
ever work on the site...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
Loren wrote:
PHP can be used as a shell scripting language like Perl, however it is
not compiled that way by default on most systems.
On UNIX systems it does not matter if an executable is named .cgi, .pl,
.php, or whatever. If the file is executable and is in a directory where
direct execution is allow (for example, in a cgi-bin directory or in the
ShopSite cgi directories), the system will check to see if it is a
binary file or a text file. If it is a binary file, if will try to
execute it directly, if it is a text file is will look for the
#!/path/to/shell/interpreter line on the first line of the file. So in
theory you can have a PHP script executed that way (#!/usr/bin/php, or
whatever), however unless you specifically know that PHP interpreter
binary was compiled to allow CGI-type execution, you can almost bet that
it was not.
When accessing PHP files directly (by URL), then they do need to be
named .php (or .php3, or .phtml), because in that case the webserver is
loading them through it's PHP module, so it needs to see those
extensions. PHP files accessed this way do not need the execute
permission bit set, but ones that are run as CGI's (see paragraph above)
do.
-Loren
Brandon Eley wrote:
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is
a completely different scripting language (though very similar) and
thus should not be named *.pl or *.cgi but only *.php, *.php4 or
*.php3 (for version numbers) or *.phtml (if your server is setup this
way - rare though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written
in perl, not PHP. Then you can name it .cgi or .pl and place it inside
your CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's
member
id from the session.
I have a very basic test script (test.php) which works fine when I
access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to
test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers
already sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The
most
common advice is to search for blank space at the beginning or end of
the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of
the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755.
Still get
same error.
If it helps, here are the first few lines of my code: There is no
space at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between
#!/usr/local/bin/php and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- tjmitoraj
Re: PHP ORDER API CGI SCRIPT
by Jim » Tue Jul 27, 2004 10:48 am
Some ISPs, such as AOL, regularly change the IP of a shopper during a
single browser session. Don't count on it to remain consistant between
sessions or even in the same session.
Jim
tjmitoraj wrote:
single browser session. Don't count on it to remain consistant between
sessions or even in the same session.
Jim
tjmitoraj wrote:
Gentlemen,
First, I appreciate your comments.
I have successfully tested a PHP style CGI and called it from the Shopsite
Order API folder.
I have encountered another hurdle and I have found a workaround, but I am
not sure if this is such a good idea!
Essentially, my Session Variables are lost when my script is called
automatically from Shopsite. I have done lots of research on this and see
it is a problem, which other people have faced. In case you are wondering,
I am calling the start_session() function at the top of my script. The
problem is when I check the session id, it is a completely new session and
none of the session variables contain the data I defined when the user
logged into my site.
One possible reason for this issue is reported in the following link -
http://support.microsoft.com/default.as ... -us;316112
and summarized here - "Security patch MS01-055 prevents servers with
improper name syntax from setting cookies names. Domains that use cookies
must use only alphanumeric characters ("-" or ".") in the domain name and
the server name. Internet Explorer blocks cookies from a server if the
server name contains other characters, such as an underscore character
("_")." Since there are lots of strange characters in some of the
Shopsite generated pages, I am not sure if this is contributing to the
problem or if the automatic order API call somehow trashes the session.
My initial workaround - I capture the users IP address when they log into my
site and then store it in my database. When the user executes an order
through Shopsite, I have my script capture the IP address again, look
through the user table in my database for a matching IP. I then lookup the
associated user. This allows me to take the Shopsite purchase data for that
user and update the other tables, pages, etc. in my database.
I suspect that this is not the best solution and have the following
questions:
- Is it secure?
- Does a user's IP address ever change in the middle of a connection?
- If the connection drops for some reason and they reconnect, does the IP
address typically change? I understand some ISPs dynamically assign them,
so this might be a problem.
- Would it be feasible to add error trapping code in my script so a changed
IP address is detected (when it sees that there is no matching IP) and the
customer/webmaster is then notified that the necessary updates will have to
be processed manually? It will be a minor inconvenience, but not too bad if
it doesn't happen regularly. This manual processing will be necessary since
the purchase was completed prior to the cgi call.
If this is not a feasible option and I can't figure out how to get the
sessions working, I might have to log in again after they make the purchase
(but that wouldn't be a very user friendly option, of course).
Any advice you can provide would be appreciated!
Thank you.
Tom Mitoraj
"Brandon Eley" <brandon@2bigfeet.com> wrote in message
news:cdmk9e$j1g$2@eval.shopsite.com...
It's probably a good idea just out of practice (and easy updating) to
name files according to what they do. Naming a php file *.pl or *.cgi
just seems confusing especially if you are not the only person that will
ever work on the site...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
Loren wrote:
PHP can be used as a shell scripting language like Perl, however it is
not compiled that way by default on most systems.
On UNIX systems it does not matter if an executable is named .cgi, .pl,
.php, or whatever. If the file is executable and is in a directory where
direct execution is allow (for example, in a cgi-bin directory or in the
ShopSite cgi directories), the system will check to see if it is a
binary file or a text file. If it is a binary file, if will try to
execute it directly, if it is a text file is will look for the
#!/path/to/shell/interpreter line on the first line of the file. So in
theory you can have a PHP script executed that way (#!/usr/bin/php, or
whatever), however unless you specifically know that PHP interpreter
binary was compiled to allow CGI-type execution, you can almost bet that
it was not.
When accessing PHP files directly (by URL), then they do need to be
named .php (or .php3, or .phtml), because in that case the webserver is
loading them through it's PHP module, so it needs to see those
extensions. PHP files accessed this way do not need the execute
permission bit set, but ones that are run as CGI's (see paragraph above)
do.
-Loren
Brandon Eley wrote:
I have some observations... first is that PHP is not CGI. You do not
need to, nor should you, put PHP scripts in your CGI-BIN or name them
*.pl or *.cgi. CGI-BIN is for executable CGI and PERL scripts. PHP is
a completely different scripting language (though very similar) and
thus should not be named *.pl or *.cgi but only *.php, *.php4 or
*.php3 (for version numbers) or *.phtml (if your server is setup this
way - rare though).
By naming a PHP script *.cgi or *.pl you are telling the web server to
treat the file as a CGI or perl script which will change what it
executes. Since the languages are different, you are not getting the
same results.
If you need a cgi script (i.e. for order api) make sure it is written
in perl, not PHP. Then you can name it .cgi or .pl and place it inside
your CGI-BIN and it will execute correctly.
Otherwise just leave the file in your htdocs or public_html directory
named *.php and execute it from there.
Hope this helps...
Brandon Eley
2BigFeet.com
brandon@2bigfeet.com
www.2bigfeet.com
tjmitoraj wrote:
I am creating a a cgi script using PHP.
In my initial test script, the basic purpose is to capture a user's
member
id from the session.
I have a very basic test script (test.php) which works fine when I
access it
with my browser. The php file is stored in my htdocs folder.
However, when I store it in the shopsite cgi-bin, rename it to
test.cgi and
make a test purchase, I get the following error:
Warning: session_start(): Cannot send session cookie - headers
already sent
by (output started at /usr/local/apache/cgi-bin/sc/test.cgi:3) in
/usr/local/apache/cgi-bin/sc/test.cgi on line 4
I have researched this on the web and see this error is common. The
most
common advice is to search for blank space at the beginning or end of
the
file. Checked that and I don't have any.
The other advice I see is to check the permissions and ownership of
the
file. I am not positive what it should be set to, but I checked the
customdump.cgi file and see it was set to www/webadmin and 0755.
Still get
same error.
If it helps, here are the first few lines of my code: There is no
space at
the top of my file.
#!/usr/local/bin/php
?
session_start();
include "verify.inc";
?
html
head
/head
body
By the way, when I tried to delete the line between
#!/usr/local/bin/php and
?, I get another error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable
to complete your request.
Any ideas on how I can resolve this situation would be appreciated.
Thank you.
Tom Mitoraj
- Jim
Re: PHP ORDER API CGI SCRIPT
by Rob » Tue Jul 27, 2004 2:15 pm
Essentially, my Session Variables are lost when my script is called
automatically from Shopsite. I have done lots of research on this and
see
it is a problem, which other people have faced. In case you are
wondering,
I am calling the start_session() function at the top of my script. The
problem is when I check the session id, it is a completely new session and
none of the session variables contain the data I defined when the user
logged into my site.
You may want to think about using cookie tracking for your sessions, and
then reading the cookie in the order API to identify the session.
and summarized here - "Security patch MS01-055 prevents servers with
improper name syntax from setting cookies names. Domains that use cookies
must use only alphanumeric characters ("-" or ".") in the domain name and
the server name. Internet Explorer blocks cookies from a server if the
server name contains other characters, such as an underscore character
("_")." Since there are lots of strange characters in some of the
Shopsite generated pages, I am not sure if this is contributing to the
problem or if the automatic order API call somehow trashes the session.
It is possible, but I do not think it checks the page names, only the root
domain name.
- Is it secure?
Sort of.
- Does a user's IP address ever change in the middle of a connection?
Yes, if they use a proxy caching server (i.e. AOL) their IP can change hit
to hit to a website.
- If the connection drops for some reason and they reconnect, does the IP
address typically change? I understand some ISPs dynamically assign them,
so this might be a problem.
This can also happen.
- Would it be feasible to add error trapping code in my script so a
changed
IP address is detected (when it sees that there is no matching IP) and the
customer/webmaster is then notified that the necessary updates will have
to
be processed manually? It will be a minor inconvenience, but not too bad
if
it doesn't happen regularly. This manual processing will be necessary
since
the purchase was completed prior to the cgi call.
Try using cookies to track sessions. They could block cookies, at which
point you could fall back to an IP number to check.
Rob
- Rob
Re: PHP ORDER API CGI SCRIPT
by tjmitoraj » Wed Jul 28, 2004 6:31 am
I think I may have stumbled upon a solution to my problem with the data
vanishing from the session variables.
Instead of calling the generic session_start() on all of my pages, I decided
to name the session that I created in the login script. I named it using
session_id("test");
Then I put session_id("test"); before the call to session_start() in my cgi.
It now works and I am able to see which user is logged in when the purchase
was made! Now I can capture the purchases made by the user and update our
database tables.
So, I am happy, although I am curious why the session variables were empty
when I called the script via the Order API. Does the shopping cart system
use sessions? Maybe my scripts are confused if there is more than one
application using the same generic session_start routine.
R,
Tom
"Rob" <rob@mangiafico.net> wrote in message
news:ce6glt$sa8$1@eval.shopsite.com...
vanishing from the session variables.
Instead of calling the generic session_start() on all of my pages, I decided
to name the session that I created in the login script. I named it using
session_id("test");
Then I put session_id("test"); before the call to session_start() in my cgi.
It now works and I am able to see which user is logged in when the purchase
was made! Now I can capture the purchases made by the user and update our
database tables.
So, I am happy, although I am curious why the session variables were empty
when I called the script via the Order API. Does the shopping cart system
use sessions? Maybe my scripts are confused if there is more than one
application using the same generic session_start routine.
R,
Tom
"Rob" <rob@mangiafico.net> wrote in message
news:ce6glt$sa8$1@eval.shopsite.com...
Essentially, my Session Variables are lost when my script is called
automatically from Shopsite. I have done lots of research on this and
see
it is a problem, which other people have faced. In case you are
wondering,
I am calling the start_session() function at the top of my script. The
problem is when I check the session id, it is a completely new session
and
none of the session variables contain the data I defined when the user
logged into my site.
You may want to think about using cookie tracking for your sessions, and
then reading the cookie in the order API to identify the session.
and summarized here - "Security patch MS01-055 prevents servers with
improper name syntax from setting cookies names. Domains that use
cookies
must use only alphanumeric characters ("-" or ".") in the domain name
and
the server name. Internet Explorer blocks cookies from a server if the
server name contains other characters, such as an underscore character
("_")." Since there are lots of strange characters in some of the
Shopsite generated pages, I am not sure if this is contributing to the
problem or if the automatic order API call somehow trashes the session.
It is possible, but I do not think it checks the page names, only the root
domain name.
- Is it secure?
Sort of.
- Does a user's IP address ever change in the middle of a connection?
Yes, if they use a proxy caching server (i.e. AOL) their IP can change hit
to hit to a website.
- If the connection drops for some reason and they reconnect, does the
IP
address typically change? I understand some ISPs dynamically assign
them,
so this might be a problem.
This can also happen.
- Would it be feasible to add error trapping code in my script so a
changed
IP address is detected (when it sees that there is no matching IP) and
the
customer/webmaster is then notified that the necessary updates will have
to
be processed manually? It will be a minor inconvenience, but not too
bad
if
it doesn't happen regularly. This manual processing will be necessary
since
the purchase was completed prior to the cgi call.
Try using cookies to track sessions. They could block cookies, at which
point you could fall back to an IP number to check.
Rob
- tjmitoraj
9 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 11 guests