Unable to write to files using CGI

I have a CGI script that worked perfect for several years that writes
contents of a file from the web on one webserver.
I am setting a new web server, and running this time the same script
but under https instead of http.
The script is very simple:


#!/usr/bin/perl
use CGI;
my $q = new CGI;
print $q->header();

$user = $q->param('user');
$pass = $q->param('pass');

if($user eq "Eduard" && $pass eq "xxxxx"){
$filecontents = $q->param('filecontents');

open(FILE,">/home/server/file.txt") or die;
print FILE $filecontents;
close(FILE);

print "hi $user!";
}
else{print "You are not authorized!"}

So, you provide something like:
http://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=xx xxx&filecontents=somedatakdfjlsdkf
This way, it should create a file called "file.txt" at the directory /
home/server/file.txt

In the new server under https I do:
https://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=x xxxx&filecontents=somedatakdfjlsdkf
But now nothing happens. The script writes only once hi Eduard!

The second print is ignored and I am not able to write or modify the
file.
I don't know if this happens because of the https. I've set the
permissions of /home/server dir to 777, and also the same for all
files inside the directory, but
I cannot write a file inside this directory.

What should I do to know what's going wrong?

Any help appreciated!

Best regards,

Alejandro


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Unable to write to files using CGI

Alejandro Santillan Iturres wrote:
> I have a CGI script that worked perfect for several years that writes
> contents of a file from the web on one webserver.
> I am setting a new web server, and running this time the same script
> but under https instead of http.
> The script is very simple:
>
>
> #!/usr/bin/perl
> use CGI;
> my $q = new CGI;
> print $q->header();
>
> $user = $q->param('user');
> $pass = $q->param('pass');
>
> if($user eq "Eduard" && $pass eq "xxxxx"){
> $filecontents = $q->param('filecontents');
>
> open(FILE,">/home/server/file.txt") or die;
> print FILE $filecontents;
> close(FILE);
>
> print "hi $user!";
> }
> else{print "You are not authorized!"}
>
> So, you provide something like:
> http://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=xx xxx&filecontents=somedatakdfjlsdkf
> This way, it should create a file called "file.txt" at the directory /
> home/server/file.txt
>
> In the new server under https I do:
> https://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=x xxxx&filecontents=somedatakdfjlsdkf
> But now nothing happens. The script writes only once hi Eduard!

I assume you mean the second and third time you call it it does nothing ?

> The second print is ignored and I am not able to write or modify the
> file.

What is the second print ? The unauthorized print ?
Is the server prompting you for a password ?

> I don't know if this happens because of the https. I've set the
> permissions of /home/server dir to 777, and also the same for all
> files inside the directory, but
> I cannot write a file inside this directory.
>
> What should I do to know what's going wrong?

What if you just strip the script to something that just appends a number
to the file and ignores everything else ? Then try it with http and then
https and see if there's any difference.

What user do you run as with https ? What OS are you running on ?

My ISP has a group HTTPS server/certificate that can be used by anyone,
but it doesn't run under your own UID, it runs as a fixed UID they set
up - it may require some major changes to the directory access
permissions of your tree. The above test working as http and failing
as https might prove it.

Add some debug prints so you know where you're getting to.
And add:
use CGI::Carp qw(fatalsToBrowser);

# try printing some Perl variables out:

print <
CGI test script report:

args are "@ARGV".



PROCESS_ID = '$$'

REAL_USER_ID = '$<'

EFFECTIVE_USER_ID = '$>'

REAL_GROUP_ID = '$('

EFFECTIVE_GROUP_ID = '$)'

PROGRAM_NAME = '$0'

PERL_VERSION = '$]'

DEBUGGING = '$^D'

SYSTEM_FD_MAX = '$^F'

HINTS = '$^H'

OSNAME = '$^O'

PERLDB = '$^P'

BASETIME = '$^T'

WARNING = '$^W'

EXECUTABLE_NAME = '$^X'
EOD

# and the %ENV and maybe INC too:

foreach (sort keys %ENV) {
print "
$_ = $ENV{$_}\n";
}
print "
\n";
print "
\@INC :\n";
print "
$_\n" foreach @INC;
print "
\n";
print "
\%INC :\n";
foreach (keys %INC) {
print "
$_ = $INC{$_}\n";
}


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Unable to write to files using CGI

I'd be looking at the server's http error log. anything the script kicked
out, msg-wise will be there. You should also put some info in your 'open'
stmt's die clause:
open(FILE,">/home/server/file.txt") or die;

s/b:
open(FILE,">/home/server/file.txt")
or die "Can't write home/server/file.txt: $!";

> I don't know if this happens because of the https. I've set the
> permissions of /home/server dir to 777, and also the same for all
> files inside the directory, but
> I cannot write a file inside this directory.

This isn't anything important is it? This seems like the worst sort of
admin flailing. There's only one file there file.txt that'd matter and
/home also needs to be open enough for the user the web server is running
as to be able to see server and file.txt. Your bare 'die' would put some
msg in the httpd error_log but by adding the info above (the "$!" would
give the human version of the OS error) it may be obvious. But you can't
do cgi programming w/o the httpd error log.

a

-------------------
Andy Bach
Systems Mangler
Internet: andy_bach@wiwb.uscourts.gov
Voice: (608) 261-5738 Fax: 264-5932

"It's true that I've driven through a number of red lights. But on the
other
hand, I've stopped at a lot of green ones I've never gotten credit for"
Glen Gould

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Unable to write to files using CGI

Hi Alejandro,

Sometimes, when a CGI script dies after having successfully printed some
content to STDOUT in a web server, it seems like it just stopped without
errors, but it's actually aborting with errors that you can only see in your
httpd logs.

If you get confused about this, I recommend the following points:


1. Add this line at the beginning of your script:

use CGI::Carp qw(fatalsToBrowser); # This will show errors on the screen


2. Whenever you "open" a filehandle, send the actual error message to the
"die" instruction through the special var "$!" like this:

open (FILE, ">myFile.txt") or die ("Cannot open myFile.txt: $!");


If you follow those two points, you're probably going to see the problem
right in your screen and you'll have a better idea of what the problem is.

Anyway, you have to look at your httpd logs to be absolutely sure. If
warnings are sent during your script execution, they will be shown only on
those logs because they're not fatal errors and might not stop the execution
at all. If you are using Apache, look into httpd.conf to see where the logs
for that specific URL are supposed to be written.


P.S. Also, you should always use "strict" and "warnings" and test your
scripts when possible in command line in order to catch obvious problems
before going through your web server. You can at least check if your syntax
is correct by calling "perl -wc yourscript.pl". While developing a script,
the use of "diagnostics" is a good idea to get better information about your
script errors or warnings (use strict; use warnings; use diagnostics;) -
....or die ;-).

HTH

Paco Zarabozo



--------------------------------------------------
From: Alejandro Santillan Iturres
Sent: Monday, March 31, 2008 4:29 PM
To: ActivePerl@listserv.ActiveState.com
Subject: Unable to write to files using CGI


I have a CGI script that worked perfect for several years that writes
contents of a file from the web on one webserver.
I am setting a new web server, and running this time the same script
but under https instead of http.
The script is very simple:


#!/usr/bin/perl
use CGI;
my $q = new CGI;
print $q->header();

$user = $q->param('user');
$pass = $q->param('pass');

if($user eq "Eduard" && $pass eq "xxxxx"){
$filecontents = $q->param('filecontents');

open(FILE,">/home/server/file.txt") or die;
print FILE $filecontents;
close(FILE);

print "hi $user!";
}
else{print "You are not authorized!"}

So, you provide something like:
http://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=xx xxx&filecontents=somedatakdfjlsdkf
This way, it should create a file called "file.txt" at the directory /
home/server/file.txt

In the new server under https I do:
https://somewebserver.com/cgi-bin/xxx.cgi?user=Eduard&pass=x xxxx&filecontents=somedatakdfjlsdkf
But now nothing happens. The script writes only once hi Eduard!

The second print is ignored and I am not able to write or modify the
file.
I don't know if this happens because of the https. I've set the
permissions of /home/server dir to 777, and also the same for all
files inside the directory, but
I cannot write a file inside this directory.

What should I do to know what's going wrong?

Any help appreciated!

Best regards,

Alejandro


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Unable to write to files using CGI

Well, as /home/anithing/ was no writable even by chmod 777 it, I've
created a new directory at:
/var/www/server/ and now, the script is able to write to a file
without problem.

My problem now is that the same script should execute something, and
it is not doing it.

The script now is:


#!/usr/bin/perl
use CGI;
my $q = new CGI;
print $q->header();

$user = $q->param('user');
$pass = $q->param('pass');

if($user eq "Eduard" && $pass eq "xxxxx"){
$filecontents = $q->param('filecontents');

#this is the line I replaced ant now the file.txt appears as expected
#open(FILE,">/home/server/file.txt") or die;
open(FILE,">/var/www/server/file.txt") or die;
print FILE $filecontents;
close(FILE);

#this is the line that is not working now:
system("wall New_file_written");

#nor this one, which is a call to another script located at /var/www/
server/
system("cd /var/www/server\n./executemyfile.pl");

print "hi $user!";
}
else{print "You are not authorized!"}


On Apr 1, 2008, at 12:10 AM, Andy_Bach@wiwb.uscourts.gov wrote:

> I'd be looking at the server's http error log. anything the script
> kicked
> out, msg-wise will be there. You should also put some info in your
> 'open'
> stmt's die clause:
> open(FILE,">/home/server/file.txt") or die;
>
> s/b:
> open(FILE,">/home/server/file.txt")
> or die "Can't write home/server/file.txt: $!";
>
>> I don't know if this happens because of the https. I've set the
>> permissions of /home/server dir to 777, and also the same for all
>> files inside the directory, but
>> I cannot write a file inside this directory.
>
> This isn't anything important is it? This seems like the worst sort of
> admin flailing. There's only one file there file.txt that'd matter and
> /home also needs to be open enough for the user the web server is
> running
> as to be able to see server and file.txt. Your bare 'die' would put
> some
> msg in the httpd error_log but by adding the info above (the "$!"
> would
> give the human version of the OS error) it may be obvious. But you
> can't
> do cgi programming w/o the httpd error log.
>
> a
>
> -------------------
> Andy Bach
> Systems Mangler
> Internet: andy_bach@wiwb.uscourts.gov
> Voice: (608) 261-5738 Fax: 264-5932
>
> "It's true that I've driven through a number of red lights. But on the
> other
> hand, I've stopped at a lot of green ones I've never gotten credit
> for"
> Glen Gould
>
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs