Archive

Posts Tagged ‘apache’

Restricetd access to a web-application with htaccess or php

July 3rd, 2009

If you building a simple web-application and you are not really sure, ow secure are the authentication and or the rest of the application you should think about to limit the access to the application.
Furthermore, may your application should be available only for testing purpose of several customers the following could help you:

First way… using a .htaccess which controls the access using a apache web server.
This is a very fast sollution BUT you CAN’T use hostnames and or full qualified dns names like skycube.net or yourname.dyndns.org

<Limit GET HEAD POST>
order deny,allow
allow from 62.75.185.219
allow from 127.0.1.1
allow from 127.0.0.1
deny from all
</Limit>

The second way… which I prefer, using a php code snippet. This allows you to use hostnames and full qualified domain names. Definitely you can write it in less than the lines I used below for the code, but in of understanding what the code does, it’s better ;)

<?php
/**
 * ACL array
 */
$valid_hosts = array();
$valid_hosts[] = 'localhost';
$valid_hosts[] = '127.0.0.1';
$valid_hosts[] = '127.0.1.1';
$valid_hosts[] = 'yourname.dyndns.org';
$valid_hosts[] = 'skycube.net';
 
for($i=0;$i<sizeof($valid_hosts);$i++){
  $valid_ip = gethostbyname($valid_hosts[$i]);
  if($valid_ip == $_SERVER['REMOTE_ADDR']){
    $valid_state = 'valid';
    break;
  }
  else{
    $valid_state = 'invalid';
  }
}
if($valid_state != 'valid')
  header("Location: http://www.skycube.net");
?>

other, php , ,

Session problems

February 21st, 2009

While you working with web applications it could happen that you get several errors.. Never underestimate real server problems. When you try to start a new Web 2.0 application or just the usage and/or visits of your application increase, maybe non-linear, you can login to your application but you can’t proceed.

On enterprise applications it’s recommended to set php display errors to off, so won’t see what really happened.

While tracking the problem to your browser and the customers and may the service provider, you should just login with a shell.
First thing you should do is, like all time, who and last. After that, may you try to find out what happen in the apache access and error log. You will find nothing, cause there is nothing critical, nothing new. May you see the session file in your filesystem, but why is it empty? A php bug?

Why? Ok just the answer, try this: df -h , you will see the a 100% full partition ;) and when you try a du -shm /var/log/* you see your problem… GB’s of apache logs…

What happened? Your Web 2.0 application uses polling, and your apache got a custom, combined log which writes to access.log.

  • Solution 1: Drop the line in your apache virtualhost configuration for custom, combined log
  • Solution 2: Proceed a massive logrotation
  • Solution 3: Pipe the combined log to a perl or php-cli script which filters the polling events (I prefer)

On local, staging and or development installations you should switch the display errors for php to on,… then you get messages like this:

WARNING: session_write_close() [function.session-write-close]...

Linux , , ,