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=xxxxx&filecontents=somedatakdfjl
sdkf
>  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=xxxxx&filecontents=somedatakdfj
lsdkf
>  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 <<EOD;
<BR> CGI test script report:
<BR> args are "@ARGV".
<BR> 
<BR> PROCESS_ID = '$$'
<BR> REAL_USER_ID = '$<'
<BR> EFFECTIVE_USER_ID = '$>'
<BR> REAL_GROUP_ID = '$('
<BR> EFFECTIVE_GROUP_ID = '$)'
<BR> PROGRAM_NAME =  '$0'
<BR> PERL_VERSION =  '$]'
<BR> DEBUGGING =  '$^D'
<BR> SYSTEM_FD_MAX =  '$^F'
<BR> HINTS = '$^H'
<BR> OSNAME = '$^O'
<BR> PERLDB = '$^P'
<BR> BASETIME = '$^T'
<BR> WARNING = '$^W'
<BR> EXECUTABLE_NAME = '$^X'
EOD

# and the %ENV and maybe INC too:

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


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