Problem with OpenId in 0.9.0 beta 5

I have just upgraded from 0.8.3 and now OpenID is not working. When I try to add an OpenID URL I just get a blank page at

http:///mydomain/settings/openid

(I have replaced my actual domain with "mydomain"). I do recall a fleeting error message that appeared when I ran the rebuilddb.sh that referenced openid, but initially everything seemed to be fine. Any suggestions?

Comments

  • I have removed all references to OpenID in config.php and still I am not having any luck getting OpenID to work. This is the error message I got when I ran rebuilddb.sh:

    ERROR 1146 (42S02) at line 401: Table 'statusnet.user_openid' doesn't exist

    Is it possible that something didn't run properly in this rebuild script? Can I check by looking for something in the database.
  • Dusting off my basic and rusty coding skills, here's what I have managed to work out so far:

    the db/statusnet.sql script does not create a user_openid table so when the dump of the original database is reloaded by rebuilddb.sh there is no table to insert the previous data into. However, the user_openid table now does exist and that seems to be because the OpenID plugin creates the table if it doesn't exist. So, since I still have a copy of the sql dump of the old database, I tried cutting out the user_openid insert commands. While that successfully inserted the old data, the problem with adding OpenID persisted.

    Since the mysql batch would have failed when the user_openid table wasn't found, no subsequent commands would have been run. All that appears in the sql file after the insert is the following:

    /*!40000 ALTER TABLE `user_openid` ENABLE KEYS */;
    UNLOCK TABLES;
    /*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

    /*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
    /*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
    /*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
    /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
    /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
    /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
    /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

    These look like comments to me, so I'm not sure whether there's anything important here that should have been done that wasn't done.

    I'm not sure what to do next in my troubleshooting. The only other thing I can think of doing is deleting all the records from oid_associations and oid_nonces.
  • what happens when you checkschema
    run /statusnet/scripts/checkschema.php

    -Aric

  • Yikes, I think the fleeting error from rebuild.sh was when the script tried to reload the table from the dump it makes but the table no longer existed!

    I believe you need to get the three OpenID tables (openid_users, oid_nonces, and oid_associations) into a consistent state. If you have existing users, hopefully you can restore those tables from backup.

    I think the proper way to upgrade from 0.8 to the latest 0.9 is to run

    db/08to09.sql
    db/rc2torc3.sql
    db/rc3torc4.sql

    on your existing DB, rather than rebuild.sh. OpenID was moved to a plugin, and is now responsible for creation of the user_openid table.

    Unfortunately, our documentation on this upgrade process isn't too good.
  • This and the README need some work inre 0.8 -> 0.9.

    http://status.net/wiki/Upgrade_notes_0.9

  • @Aric didn't know about that script. Thanks, I'll give it a try. @zcopley unfortunately since everything else was running fine, and it solved my Twitter problem, I kept running with 0.9.0beta5 so I've now got quite a lot of new data since the 0.8.3 db dump. Is it safe to run those scripts on my current 0.9 db? I only have 3 OpenID users at the moment so can live with losing the oid data. I did try just deleting all the data from oid_subscriptions and oid_nonces (leaving user_openid also empty) but that didn't seem to help.
  • I mean "oid_associations" not "oid_subscriptions".

    Also, I've had a closer look at 08to09.sql and the others, and they don't seem to reference the oid tables. I'm hoping that my other data is essentially ok, and there's just an OpenID problem to solve now!
  • Note that when I say I get a blank page at

    http:///mydomain/settings/openid

    I mean that I never even make it as far as a page of the OpenID provider. Are there some debug settings I should try turning on? Should I drop the oid tables completely?
  • OK, here's my plan (won't do it yet, so please let me know if it's foolish!). I have extracted the sections for oid_associations, oid_nonces and open_userid from my 0.8.3 mysql dump. I plan to drop these three tables (and user_openid_trustroot which doesn't seem to exist in 0.8.3. Then I will run the edited script to recreate the first three tables. Is this likely to help?
  • No overwhelming objections, so about to give this a try!
  • Well I tried that and it didn't work. When I try to log in using OpenID it still sends me to a blank page and doesn't make it to the OpenID provide. Also, since I repopulated user_openid, the OpenID tab on my account page list my previously registered OpenID url (set back when OpenID was working under 0.8.3), but if I try to press delete, nothing happens. Nothing useful appears to be in the logs.
  • Problem solved!

    in extlib/Auth/OpenID/CryptUtil.php there is a reference to /dev/urandom and this does not exist on my server. For now I have changed this to null and OpenID now works.
  • Hmm, try pointing it to dev/random. Openid is generating keys, so you need the random part.

    which os is this that has no dev/urandom? Solaris?
  • It is debian. When I do an ls now, both random and urandom appear, but I still get errors if either are used in the script.
  • strange, any developments? any debug output? logdebug=true
  • I tried setting logdebug=true; and then get a blank screen when I try to access the StatusNet site. So, I instead set $config['site']['logdebug'] = true; and then switched back to /dev/urandom and OpenID still would not pass through to the OpenID provide, but I get no messages in the log file.
  • yeah, my lazy.

    add this for full db debugging

    $config['db']['debug'] = create_function('$class, $message, $logtype, $level','common_log(LOG_DEBUG,"DBDO: $class / $message / $logtype");');
  • Wow! That certainly spits out a lot of logging! Anyway, I switched to /dev/urandom, attempt to connect via OpenID (and was not redirected to the OID provider), switched back to NULL in CryptUtil.php and sucessfully connected. It's all in the log file, but what should I be looking for in there now?
  • If your searching for the best site about a vizio xvt3d650sv or a vizio television in general. Then look here vizio xvt3d650sv or vizio review
  • The previous comment is spam.

    // Paul
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID