I have been learning PHP on my own and I've used a web host account to test my scripts, where they have register_globals on by default. I know that this is not secure but I haven't bothered when just testing sample code.
Now I'm working on a small live site for a non-profit organization I'm a member of and the host they are using have register_globals off by default, as it should be.
So, now my question. I have been used to this working (with register_globals on):
Presume we are loading index.php?pID=1. The code of index.php will contain this row:
if($pID==1) include('content1.php');
Note that I've used $pID and not $_GET['pID'] and that I haven't assigned $_GET['pID'] to $pID anywhere in my code. This has worked fine anyway. So (of course) I'm wondering if it's because of register_globals being off that this is suddenly not working when I'm using the same code on my orgs host?
If so, is there a work-around to make superglobals magic again or do I have to live with manually assigning all $_GET variables to my own globals?
DO NOT attempt to implement register_globals, it is a massive security hole and never should have been implemented in the first place. Hence why it was deprecated in PHP 5.3 and removed in PHP 5.4.
You don't need to re-assign your variables, just replace them with the $_GET equivalents. I.E.
if($pID==1) include('content1.php');
should become
if($_GET['pID']==1) include('content1.php');
To demonstrate why register_globals was bad, take a look at this simplified example:
if(login_success('admin')) {
$admin = 1;
}
if($admin == 1) {
require('super-secret-admin-file.php');
}
Because $admin is never initialized anywhere, if register_globals was on and you opened file.php?admin=1 you would gain access to the admin section of the site regardless of if you are an admin or not.
Related
I am working on transferring one application from rgen to Origen.
I added environment/j750.rb in my application.
added the below code into j750.rb
# environment/j750.rb
$tester = OrigenTesters::J750.new
in Target folder, I also added $test as below:
$tester = OrigenTesters::J750.new
however, when I tried to generate pattern, it still failed and showed'uninitialized constant OrigenTesters'.
When and how to initialize it?
Thanks a lot in advance!
Normally this is something that Origen users don't particularly need to worry about, if you add:
gem 'origen_testers'
to your application's Gemfile, then it will be required automatically and a reference like OrigenTesters in your environment file or anywhere else will just work.
However, I note that you mention upgrading from an rgen app, which means that your application must be very old and in fact may not even have a Gemfile.
If you contact me internally I can send you the link to our intranet page which has a guide on how to update these really old apps.
Few moments ago I realised that symfony prints out all exceptions in my prod env. How can I turn this off?
After a little bit of looking, it seems this is how to (there is probably a better solution but I couldn't find it).
Under web/app.php, change $kernel = new AppKernel('prod', true); - the true here sets display_errors to true, so just change it to false.
If that fails, you should ensure that display_errors is turned off (if it's production, probably best done in php.ini itself rather than using ini_set).
I read #Dmitri 's original example of how to use fastcgi_finish_request() question and tried to follow the example in the answer in my Kohana 3.1 setup in index.php:
echo Request::factory()
->execute()
->send_headers()
->body();
Right after that, I added:
fastcgi_finish_request();
sleep(5);
Initially, I thought it worked. But then I realised in only worked for every other request. Example:
Navigate to localhost (works, no pause)
Click link to localhost/controller (pause 5 seconds)
Click another link to localhost/controller (works again, no pause)
And it continues on like that. Am I missing something? Like maybe a setting in php5-fpm config file?
Running PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch, Nginx
Call session_write_close() before you call fastcgi_finish_request() to resolve this issue:
session_write_close();
fastcgi_finish_request();
sleep(5);
Next to the server-response itself (which you can control with the fastcgi_finish_request function and rest assured it works that way), there can be other resources that is blocking the (next) script from starting right ahead.
This can be file-lockings (popular for session) and other stuff. As you have not shared much code and we do not see your Kohana configuration you should take a look which components you use and which resources they acquire.
Is it because your web server only handles one php instance at a time and it is still exciting the previous script?
We have a custom site written in Perl that uses a slightly modified version of CGI.pm. During server updates, CGI.pm may be overwritten when it is updated. My goal is to be able to update the server without affecting the site - i.e. change the code that relies on the modified CGI.pm. Unfortunately I am not very familiar with Perl syntax or best practice.
Here is a diff of the modified CGI.pmn (line numbers are off from the most recent version of CGI.pm):
--- CGI.pm.orig Tue Nov 7 12:14:09 2006
+++ CGI.pm Tue Nov 7 12:13:29 2006
## -3386,7 +3386,7 ## sub read_multipart {
if (defined $self->{'.upload_hook'})
{
$totalbytes += length($data);
- &{$self->{'.upload_hook'}}($filename ,$data, $totalbytes, $self->{'.upload_data'});
+ &{$self->{'.upload_hook'}}($filename ,$data, $totalbytes, $self->{'.upload_data'}, $param, $header{'Content-Type'});
}
print $filehandle $data if ($self->{'use_tempfile'});
}
The code that relies on this diff follows:
my %file_hash = ();
my $page = new CGI(\&file_reader, \%file_hash, 0);
my $session = &get_session($page);
foreach my $param_name (keys %file_hash) {
my $notes_param = $param_name . "_notes";
&store_file($file_hash{$param_name}, $page->param($notes_param),
&get_session_name($session));
}
Without the diff, when the file is stored, the $param_name variable appears to be empty.
What is the best way to handle this? As I said before, my main goal is to simplify updates to the server; is there some way to either
a) (preferably) get %file_hash to work properly without a modified version of CGI.pm
b) prevent updates to CGI.pm (and is this a bad idea)
Have you tried submitting this to the CGI RT as a desired improvement? It seems reasonable to pass $param and \%header (rather than $header{'Content-Type'}) to the callback.
To answer your question, you could install CGI in a local directory. The directories in the PERL5LIB env var are searched first, so your CGI version would be found instead of the one installed by the Ubuntu.
I'm the CGI.pm maintainer. I think there is a better option than using a local copy of CGI.pm. Instead, create a sub-class, and use the my subclass in your application. It would look like this:
package My::CGI;
use parent 'CGI';
sub my_sub_that_modified {
...
}
1;
So, you just need to copy in the subroutine that you modified. Then, when you upgrade CGI.pm, you likely don't need to touch your application, unless your modified subroutine changes.
With the "local lib" option, you would still need to manually merge in security updates and other changes you might want to into your local copy. The sub-class route minimizes that.
An example of this approach is Bugzilla::CGI which makes several changes in their sub-class.
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');