update to svn HEAD broke stuff

[Rich Bowen]

Yeah, I know, running out of svn HEAD is not a supported configuration. I'm not complaining, per se. I know that doing that is prone to break stuff.

So, having said that ...

I've spent the last 2 hours trying to log into my own website. I svn up'ed from possibly 100 revs ago, and would appreciate suggestions as to what is likely to have changed in that time, regarding logins in particular, that might cause me to not be able to log in.

It was suggested that I empty my rewrite_rules table, which I have done, with the result that per-tag atom feeds no longer work, but I can still not log in. I dropped the records in my users table and re-ran the install, which recreated the user records (with {SSHA512} rather than {SSHA} in the password, I note) but still can't log in.

I've tried a variety of things that have had no effect that I can tell, and I'm at the point of frustration where I'm sure I'm blind to the obvious. Any suggestions would be greatly appreciated.

It was my intent to write some Habari code today - I even had a particular itch in mind - but now I've consumed the entire available time just trying to log in.

--

Whatever you do will be insignificant, but it is very important that you do it.

Mahatma Ghandi

[Rich Bowen]

On Nov 24, 2007, at 13:45, Rich Bowen wrote:

Yeah, I know, running out of svn HEAD is not a supported configuration. I'm not complaining, per se. I know that doing that is prone to break stuff.

So, having said that ...

I've spent the last 2 hours trying to log into my own website. I svn up'ed from possibly 100 revs ago, and would appreciate suggestions as to what is likely to have changed in that time, regarding logins in particular, that might cause me to not be able to log in.

It was suggested that I empty my rewrite_rules table, which I have done, with the result that per-tag atom feeds no longer work, but I can still not log in. I dropped the records in my users table and re-ran the install, which recreated the user records (with {SSHA512} rather than {SSHA} in the password, I note) but still can't log in.

For whatever it's worth, when I put in an incorrect username and/or password, it very clearly tells me that I've entered invalid login information. When I enter valid information, it sends me back to the login form, with no "bad password" notification. Debug prints placed various places tell me that the password verified successfully.

--

What the world needs is more geniuses with humility, there are so few of us left.

Oscar Levant

[Robin Adrianse]

I think you would have to drop your tables and rebuild, at least as far as I know. Owen sent out an email to that effect a few days ago, IIRC. That might explain your wacky sessions.

[Rich Bowen]

On Nov 24, 2007, at 15:06, Robin Adrianse wrote:

I think you would have to drop your tables and rebuild, at least as far as I know. Owen sent out an email to that effect a few days ago, IIRC. That might explain your wacky sessions.

Drop specifically *which* tables? Clearly, I'm not going to drop my posts table. I followed Owen's instruction to drop the 'sessions' table, with no useful results. However, my upgrade state doesn't match the criteria for dropping the sessions table, so that didn't surprise me much. 

While I appreciate the suggestion, it sounds like you're guessing, and I've been working on guesses for more than 3 hours now with no positive results.

--

Rich Bowen

rbo...@rcbowen.com

[Rich Bowen]

On Nov 24, 2007, at 14:12, Rich Bowen wrote:

For whatever it's worth, when I put in an incorrect username and/or password, it very clearly tells me that I've entered invalid login information. When I enter valid information, it sends me back to the login form, with no "bad password" notification. Debug prints placed various places tell me that the password verified successfully.

Oh, and from the habari__log table:

| 433 |       1 |       3 |           3 | Successful login for rbowen                                                                                                                                                                                                                                     | NULL | 2007-11-24 15:52:21 | 

Is there supposed to be something in user_info or permissions that indicates that it's an admin account?

--

If you miss this moment

You miss your life

[Owen Winkler]

Rich Bowen wrote:
>
> Is there supposed to be something in user_info or permissions that
> indicates that it's an admin account?

Unless you've added permissions to the permissions table, Habari doesn't
check for permissions other than a valid login.

Owen

[Rich Bowen]

Well, I did a completely fresh installation, on a completely new database, and *still* can't log in, although the logs table assures me that I've successfully logged in.

Sufficient frustration for one day. Perhaps inspiration will come to me tomorrow.

--

We are here and it is now.

Further than that all human knowledge is moonshine.

H.L.Mencken

[Scott Merrill]

Rich Bowen wrote:
> Well, I did a completely fresh installation, on a completely new
> database, and *still* can't log in, although the logs table assures me
> that I've successfully logged in.
>
> Sufficient frustration for one day. Perhaps inspiration will come to me
> tomorrow.

Might there be something with your configuration of PHP that doesn't
like the session handling code recently added?

Are there any entries in the session table? Once you've logged in, you
should register a record in the session table, I think.

--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/

[Rich Bowen]

On Nov 24, 2007, at 20:59, Scott Merrill wrote:

Rich Bowen wrote:

Well, I did a completely fresh installation, on a completely new

database, and *still* can't log in, although the logs table assures me

that I've successfully logged in.

Sufficient frustration for one day. Perhaps inspiration will come to me

tomorrow.

Might there be something with your configuration of PHP that doesn't

like the session handling code recently added?

Do you have something particular in mind?

Are there any entries in the session table?  Once you've logged in, you

should register a record in the session table, I think.

Yes, there are entries logged in the session table. However, I note that they all have user_id set NULL.

--

"Reality is that which, when you stop believing in it, doesn't go away." (Philip K. Dick)

[Scott Merrill]

Rich Bowen wrote:
>> Might there be something with your configuration of PHP that doesn't
>> like the session handling code recently added?
>
> Do you have something particular in mind?

Nothing in particular: I don't know much about PHP session handling, but
if you've rolled your own PHP then perhaps you selected some
non-standard compilation options. Unlikely, I guess.

>> Are there any entries in the session table? Once you've logged in, you
>> should register a record in the session table, I think.
>
>
> Yes, there are entries logged in the session table. However, I note that
> they all have user_id set NULL.

I haven't dabbled with the session code yet, but a quick look suggests
that a die() around line 75 of user.php might be able to let you know
whether the user id is being returned from the session.

Line 137 is where the session data actually gets stored, so you could
check what happens there, too.

[Rich Bowen]

On Nov 25, 2007, at 00:26, Scott Merrill wrote:

Rich Bowen wrote:

Might there be something with your configuration of PHP that doesn't

like the session handling code recently added?

Do you have something particular in mind?

Nothing in particular: I don't know much about PHP session handling, but

if you've rolled your own PHP then perhaps you selected some

non-standard compilation options.  Unlikely, I guess.

Ah. I'm running standard PHP from the FC7 packages on the machine in question.

Are there any entries in the session table?  Once you've logged in, you

should register a record in the session table, I think.

Yes, there are entries logged in the session table. However, I note that

they all have user_id set NULL.

I haven't dabbled with the session code yet, but a quick look suggests

that a die() around line 75 of user.php might be able to let you know

whether the user id is being returned from the session.

Line 137 is where the session data actually gets stored, so you could

check what happens there, too.

The login happens successfully, the ID number is set correctly (at least in code). I suspect that the cookie isn't being received, or isn't being returned, but I'm not sure how to verify this. Several cookies are set, but I don't know how to determine if the correct data is being set in them. Or, more relevantly, whether it is being returned. This is, to say the least, enormously frustrating.

Point of data - I noticed that when I was using the hostname 'wooga.drbacchus.com' it sets the cookie for the domain '.wooga.drbacchus.com' whereas when I use www. drbacchus.com it sets it for '.drbacchus.com'  Probably doesn't matter - it still doesn't work for 'www.drbacchus.com'

Anyways, the cookie is sent, but forget() is never called, which is what suggests to me that the cookie just isn't sent back. But how to address this, I don't know just yet.

--

One of the advantages of being disorderly is that one is constantly making exciting discoveries.

A. A. Milne

[Rich Bowen]

Found it: in session.php

                $subnet = ip2long($_SERVER['REMOTE_ADDR']) >> 8;                             

                if($session->subnet != $subnet) {                                            

                        $dodelete = true;                                                    

                } 

That's the piece of code that is causing my session to get invalidated.

Commenting out that block allows me to use my site again.

Can someone explain to me what that is supposed to be doing? What does >> do?  I suppose I could do a little research, but 6 hours into this process I'm just too frustrated, and am just glad to have a solution.

Grr.

--

Happiness isn't something you experience; it's something you remember.

Oscar Levant

[Scott Merrill]

Rich Bowen wrote:
> $subnet = ip2long($_SERVER['REMOTE_ADDR']) >> 8;
>
> if($session->subnet != $subnet) {
>
> $dodelete = true;
>
> }

...

> Can someone explain to me what that is supposed to be doing? What does
>>> do? I suppose I could do a little research, but 6 hours into this
> process I'm just too frustrated, and am just glad to have a solution.

That bit of code makes sure that the first three octets of your IP
address are the same between visits. The intent is to ensure that your
session is being used from the same network each time, while still
allowing for (some) configurations that use more than one proxy server.

I'm not sure how the ">>" operation works, either, but it's bitwise math
explained here:
http://us2.php.net/manual/en/language.operators.bitwise.php

[Rich Bowen]

Evidently, then, it's not actually working. I'm accessing the server across the LAN, and have a static DHCP reservation. Ok, I'll poke around some more and see if it's working, why it's not working in some situations, and why it seems to be working in others. Thanks for the pointer.

[Matthias Bauer]

On 2007-11-25 15:41 Rich Bowen wrote:

>> Rich Bowen wrote:
>>> $subnet = ip2long($_SERVER['REMOTE_ADDR']) >> 8;
>>>
>>> if($session->subnet != $subnet) {
>>>
>>> $dodelete = true;
>>>
>>> }
>>

>> That bit of code makes sure that the first three octets of your IP
>> address are the same between visits. The intent is to ensure that your
>> session is being used from the same network each time, while still
>> allowing for (some) configurations that use more than one proxy server.
>

> Evidently, then, it's not actually working. I'm accessing the server
> across the LAN, and have a static DHCP reservation. Ok, I'll poke around
> some more and see if it's working, why it's not working in some
> situations, and why it seems to be working in others. Thanks for the
> pointer.

This is a wild guess, but are you running on a 64bit architecture? Also,
could you tell us the output of ip2long($_SERVER['REMOTE_ADDR']) and
ip2long($_SERVER['REMOTE_ADDR']) >> 8?

-Matt

[Rich Bowen]

On Nov 25, 2007, at 13:38, Matthias Bauer wrote:

This is a wild guess, but are you running on a 64bit architecture? Also,

could you tell us the output of ip2long($_SERVER['REMOTE_ADDR']) and

ip2long($_SERVER['REMOTE_ADDR']) >> 8?

No, I am not, I'm running:

[rbowen@buglet ~]$ cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 15

model           : 6

model name      : Intel(R) Celeron(R) D CPU 3.46GHz

stepping        : 5

cpu MHz         : 3467.087

cache size      : 512 KB

... etc

$_SERVER['REMOTE_ADDR'] = 192.168.200.1

ip2long($_SERVER['REMOTE_ADDR']) = -1062680575

ip2long($_SERVER['REMOTE_ADDR']) >> 8 = -4151096

I must confess I have no idea what that might signify, but I can't quite imagine that those should be negative numbers.

--

Rich Bowen

rbo...@rcbowen.com

[Rich Bowen]

It might be worthwhile to determine these numbers from your end, too: http://drbacchus.com/x.php

However, whatever odd value it returns, I'd expect it to return the *same* odd values, given the same IP address. Right?

--

Speech is conveniently located midway between thought and action, where it often substitutes for both.

    John Andrew Holmes

[Rich Bowen]

On Nov 25, 2007, at 14:23, Rich Bowen wrote:

$_SERVER['REMOTE_ADDR'] = 192.168.200.1

ip2long($_SERVER['REMOTE_ADDR']) = -1062680575

ip2long($_SERVER['REMOTE_ADDR']) >> 8 = -4151096

Hold on a second, that's the address of my wireless router, not the address of the client machine. Is that expected?

Curiouser and curiouser.

--

"That's what being alive IS ... It's being badly prepared for everything!

Because you only get one chance ... You only get one chance and then you die

and they don't let you go round again after you've got the hang of it!"

_The Bromeliad Trilogy_, Terry Pratchett

[Owen Winkler]

Rich Bowen wrote:
>
>> $_SERVER['REMOTE_ADDR'] = 192.168.200.1
>> ip2long($_SERVER['REMOTE_ADDR']) = -1062680575
>> ip2long($_SERVER['REMOTE_ADDR']) >> 8 = -4151096

> However, whatever odd value it returns, I'd expect it to return the
> *same* odd values, given the same IP address. Right?

The schema stores the value in an UNSIGNED field. Likely, it's doing
some bad bit math during the conversion in or out of the database. Any
PC with a remote_addr with a first octet higher than 127 should exhibit
this issue, since that's the "sign" bit. This also explains why it
works for some users (everyone but Rich) and not others, since it would
depend on the IP address you accessed the server from.

Anyone have a fix for this? I think got a D on that signed/unsigned
test in computer class in high school. We could always change the
schema to allow signed integers, I suppose.

Owen

[Scott Merrill]

Owen Winkler wrote:
> Rich Bowen wrote:
>>> $_SERVER['REMOTE_ADDR'] = 192.168.200.1
>>> ip2long($_SERVER['REMOTE_ADDR']) = -1062680575
>>> ip2long($_SERVER['REMOTE_ADDR']) >> 8 = -4151096

...

> The schema stores the value in an UNSIGNED field. Likely, it's doing
> some bad bit math during the conversion in or out of the database. Any
> PC with a remote_addr with a first octet higher than 127 should exhibit
> this issue, since that's the "sign" bit. This also explains why it
> works for some users (everyone but Rich) and not others, since it would
> depend on the IP address you accessed the server from.
>
> Anyone have a fix for this?

We could use IP addresses as strings, rather than convert them to true
integers.

This should work:
$ip= $_SERVER['REMOTE_ADDR'];
$end= strrpos( $ip, '.');
$subnet= substr( $ip, 0, $end);
Then just store the string value of $subnet in the DB. Maybe less
elegant, but it does make troubleshooting a little easier.

[Owen Winkler]

Scott Merrill wrote:
>
> We could use IP addresses as strings, rather than convert them to true
> integers.
>
> This should work:
> $ip= $_SERVER['REMOTE_ADDR'];
> $end= strrpos( $ip, '.');
> $subnet= substr( $ip, 0, $end);
> Then just store the string value of $subnet in the DB. Maybe less
> elegant, but it does make troubleshooting a little easier.
>

True, this would work. The reason I didn't do this is because it runs
this check on every page view, and I was eeking out a bit of performance
using bitwise math.

I think it's worthwhile to try changing the field in Rich's database (if
he's willing) to be not unsigned, to see if that fixes things, and then
if it doesn't, I have no problem using the string method you've
supplied. We can always figure out what went wrong with the bit math
later and change the code back if we wanted.

Is this not working anywhere else? Does anyone else have this problem?

Owen

[Rich Bowen]

On Nov 25, 2007, at 15:04, Owen Winkler wrote:

Scott Merrill wrote:

We could use IP addresses as strings, rather than convert them to true

integers.

This should work:

$ip= $_SERVER['REMOTE_ADDR'];

$end= strrpos( $ip, '.');

$subnet= substr( $ip, 0, $end);

Then just store the string value of $subnet in the DB.  Maybe less

elegant, but it does make troubleshooting a little easier.

True, this would work.  The reason I didn't do this is because it runs 

this check on every page view, and I was eeking out a bit of performance 

using bitwise math.

I think it's worthwhile to try changing the field in Rich's database (if 

he's willing) to be not unsigned, to see if that fixes things,

Changing that field to signed, rather than unsigned does indeed fix the problem. A million thanks.