Greetings,

I've been lurking for several weeks, I thought I'd post to describe
a problem I've been having in the hope that a solution can be found.
And my thanks to Casey, for his offlist assistance with another,
unrelated issue earlier this week. :-)

I apologize up front, for what is probably too much information.
I know this will take some time to read and digest.

On a client's site (PHP4 environment, natch), two login "methods" are
used to control access to premium content. The first sets a cookie
when valid access codes are submitted via the login form, there are
no known problems with that method at this time.

The second method was grafted on top of the first by a 2nd programmer.
It is a link to the verification script (index1.php) that is supposed
to do IP lookups in a MySQL db table. The table is called "getIPval"
and has 4 Fields, which are named 'nIP','ipStart','ipEnd','nStatus'

All ipStart/ipEnd ranges have a status of "1", and can accommodate
the number of characters required for IPv6 addresses but to the best
of my knowledge, no IPv6 addresses are listed at this time (there are
a couple thousand line items).

The script(s) is supposed to check rows in the table and if the
requesting IP is >= ipStart AND <= ipEnd on a given row, grant
access to the requesting IP [load the page identified by the rYear
(decade) & year (actual year) variables called out in the navigation
link] - the default page after login is /1940s/1949.php . If the
requesting IP is not found, the user is to be bounced to the login
page [index.php]. Outside of these two scripts, the 'rYear'and 'year'
values are passed via GET in the navigation links, the "key" is not
passed by the navigation links. To repair emergent problems with the
1st access method while getting the 2nd access method to work, the
"key" was introduced but it is not included in the navigation links.
An example nav link looks something like this:

http://[domain][path]index1.php?rYear=value1&year=value2

Or at least, that is how it is all supposed to work, per my
understanding of the programmer's description and my own understanding
after reviewing the code myself.

The Problem
A growing number of what are supposed to be authorized, IP-authenticated
users have reported an inability to navigate away from the initial
premium content page, 1949.php, after the script checks their IP and
lets them in that far. Access code users do not report difficulties.

I've been over this with the programmer, he says he cannot find
anything wrong with the PHP scripts. I've checked some of the affected
IP-range entries in the MySQL db table, our best guess to date has
been that a cache server is misbehaving somewhere. Neither of us is
able to duplicate the reported error of not being able to navigate
away from the 1949 page.
What I have observed recently however, with my own IP listed in the
db table as part of a range, sometimes the script will randomly either
let me in or not let me in. Whichever state it is in, persists, until
new changes are made when it will then either let me in or not.
It always lets me in if I list my specific IP (not as part of a range).

So as the number of users who report the navigation difficulty grows,
I am beginning to wonder if there might really be a problem in the
script that the programmer isn't seeing for whatever reason. Does
anyone see anything obviously wrong in the code below?

I've obscured the actual server domain name, login, passwords, and some
path statements. Watch for line wraps.

Reese

--

<?php
//
//login script, invoked by all premium content pages via GET
//file name index1.php
//
$link = mysql_connect('mysql_server_url', 'login_id', 'login_password');
if (!$link) {
die('Not connected : ' . mysql_error());
}
// make mrfsql_db1 the current db
$db_selected = mysql_select_db('login_id', $link);
if (!$db_selected) {
die ('Can\'t use foo : ' . mysql_error());
}
$domain = GetHostByName($REMOTE_ADDR); // users IP//
if(!empty($_REQUEST['rYear']))
{
$yrs = $_REQUEST['rYear'].'s';
$yr = $_REQUEST['year'];
}
function getIP($cdomain)
{
$sql = "SELECT nStatus FROM getIPval WHERE ipStart ='".$cdomain."' ";
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
return $row['nStatus'];
}
$row = getIP($domain);
if(!empty($_COOKIE["monthcode"]))
{
$pcode = $_COOKIE["monthcode"];
}
if($row == '1' || $pcode!='')
{
header("Location: decade/$yrs/$yr.php?key=1");
}
else
{
$sdomain = explode(".",$domain);
$cdomain = $sdomain['0'].'.'.$sdomain['1'].'.'.'0'.'.'.'0';
$row = getIP($cdomain);
if($row == '1' && $sdomain['3'] <256)
{
header('Location: decade/1940s/1949.php?key=1');
}
else
{
header('Location: index.php');
}
}
?>
EOF

Below, the check script that is used on all other premium pages.
Its intended function is to verify that the user is authorized
and if they are not, bounce them back to the login page (index.php).
It also obscures the true path to premium-content PDF downloads.
Both scripts (above and below) are accessed regardless of access
code or IP-check-based logins, so that may be a bit confusing:

<?php
//
//check script, is an include() on all premium content pages
//
if(!empty($_REQUEST['nme']))
{
$sPromocode = 'alphanumeric_code1';
}
elseif($_REQUEST['key'])
{
$sPromocode = 'alphanumeric_code1';
}
else
{
$sPromocode = $_COOKIE["monthcode"];
}
$twoyears = array('alphanumeric_code1', 'alphanumeric_code2',
'alphanumeric_code3', 'alphanumeric_code4', 'alphanumeric_code5',
'alphanumeric_code6', 'alphanumeric_code7');
$key = in_array($sPromocode,$twoyears);
if($key=='0')
{
header('Location: ../../index.php');
}
if(!empty($_REQUEST['action']))
{
if($_REQUEST['action']=='pdf')
{
$nme = $_REQUEST['nme'].'.pdf';
$filename = '[PATH]'.$nme;
$filename = realpath($filename);
$file_extension = strtolower(substr(strrchr($filename,"."),1));
switch ($file_extension) {
case "pdf": $ctype="application/pdf"; break;
default: $ctype="application/force-download";
}
if (!file_exists($filename)) {
die("NO FILE HERE");
}
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0,
pre-check=0");
header("Cache-Control: private",false);
header("Content-Type: $ctype");
header("Content-Disposition: attachment;
filename=\"".basename($filename)."\";");
header("Content-Transfer-Encoding: binary");
header("Content-Length: ".@filesize($filename));
set_time_limit(0);
@readfile("$filename") or die("File not found.");
}
}
?>
EOF

Someone?

-----
http://ooyes.net Web design company | http://ooyes.net Graphic design
company | http://ooyes.net Outsourcing company
--
View this message in context: http://www.nabble.com/Login-script-p...p14618942.html
Sent from the PHP - General mailing list archive at Nabble.com.

[snip="all"]

Reese,

While I noticed several areas for improvement in the code (such as
being sure to exit; after calling header("Location: xxxx"); ), two
things primarily come to mind:

Do you expect the value of $key in this condition to be a literal zero?
$twoyears = array('alphanumeric_code1', 'alphanumeric_code2',
'alphanumeric_code3', 'alphanumeric_code4', 'alphanumeric_code5',
'alphanumeric_code6', 'alphanumeric_code7');
$key = in_array($sPromocode,$twoyears);
if($key=='0')

Also, what about ISPs such as AOHell who use fully-dynamic IP
proxies that change on location, at time intervals, and are
interspersed with random changes? Even putting that into a range
won't help, as it's likely the IP will only have the network prefix
(and perhaps the same Class B slot).

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

No, it should either be "1" if set or NULL(?) if not set, there is
nothing to set that value to "0" - only this check to see if it is
== to "0". Is this another area, like the one Casey helped with
earlier, where '!empty' was being used instead of 'isset'?

The programmer is aware that improvement is possible and we've had
some discussions in that regard, but owing to this being a "for a
friend" item and his currently declared job demands, either he is
truly swamped or he is brushing me off. I'm willing to give him
benefit of the doubt, until I'm confronted with evidence to the contrary.


That's an area where I left detail out, my apologies. The dual login
mechanisms are geared towards accommodating this, AOHell users will
tend to be individual entities and the 'access code' mechanism is
geared towards them. Meanwhile, entities with static, assigned IP
addresses such as libraries on city networks are meant to be given
IP-based access, hence the other login validation method (which
isn't working quite right).

Reese

Me3!!!!1!1!1ONE

Please, if you do not need amplifying information or if you do
not intend to pose a suggestion, it is better to remain silent.
I wasn't helped by your "Someone?" post, no one else was either.

Reese

It's just some jackass who's replying to random posts to SPAM the
links in his/her signature, I'm sure. Ridiculous posts have been made
in other threads from "Web Design Company" as well.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

That's because isset() isn't able to eval() an expression. Remove
the !isset() part, or the =='1' part and that will remove the parse
error.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

Got it, I see the mistake now.

I changed it to if(!isset($key)) and you were right, the parse error
went away. This change seems to have no effect on access code logins
(I'm able to log in, as expected) or IP-authenticated logins (I still
cannot log in, even though my IP is in the MySQL db).

Reese