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
> 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
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.
On Nov 24, 2007 10:45 AM, Rich Bowen <rbo...@rcbowen.com> 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.
> 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
> 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.
> 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?
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
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.
> 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)
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 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
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
> } ... > 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.
>> } > ... >> 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.
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.
-- Whatever you do will be insignificant, but it is very important that you do it. Mahatma Ghandi
>> 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?
> 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
> 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
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
>> $_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 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.
> 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?
>> 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.
-- "Reality is that which, when you stop believing in it, doesn't go away." (Philip K. Dick)
