OpenID

# I couldn't find Auth_OpenID_DatabaseConnection anywhere,
which
# Drupal_OpenID_DBConnection attempts to extend

Well, I didn't expect anyone to actually try running the
module; it's
just for viewing and has been developed against an
unreleased version
of our PHP OpenID library.  I guess
what I am looking for (with
regard to the code specifically) is "that should work
and is
acceptable", "don't do that, that's terribly
awful", or "You'e almost
there, but here are some things to consider."  But I'll
take a test
run, too, for sure. 

# but I worked around this by requiring DB/mysql.php and
extending
# DB_mysql instead. This at least let me get as far as
getting the
# other server to ask if I trusted my test site. However, on
returning
# to my test site, I didn't seem to be any more logged in
than I was
# before. Could this be caused by the missing
# Auth_OpenID_DatabaseConnection?
#
# <snip>
#
# Help here would be appreciated.

Thanks for the detailed reply, and thanks for going to the
trouble to
get it to work.  Your decision to extend DB_mysql was
correct.  Check
to be sure that the openid_* tables are in your Drupal
database.  Did
you get any kind of error when you return to your site from
the OpenID
server?  (If you made it that far, things appear to be in
working
order.)  When you return to your test site, do you get
prompted to
enter an email address for the new account?  If so, does
that succeed?

# I take it openid_login_form_submit() would be an
appropriate place
# to add a check for banned servers? eg. Allowing the
administrator to
# ban all OpenID users from spammers.com.

Yeah, that's right.

Thanks!

--
  Jonathan Daugherty
  JanRain, Inc.

Stop me if you've heard this one before.

I recently upgraded the server running my Drupal site, and
the events 
calendar stopped working for everyone except user=1.  I
tracked down the 
problem to this (simplified) line of SQL:
SELECT n.nid, e.event_start FROM  e INNER JOIN 
n ON n.nid 
= e.nid
This returns all my events if the user=1, and zero if the
user is anyone 
else.
However, if I rewrite the SQL as:
SELECT n.nid, e.event_start FROM  n INNER JOIN 
e ON n.nid 
= e.nid
then it behaves as I would expect, returning all events
regardless of 
who the user is.

I did not have this problem on my old server, which was
running mysql 
4.0.20-max.  The new server is running mysql 5.0.17.

I suspect whatever is causing this is also at the root of my

node_access_by_role issue (http://drupal.org/node/4
0623).  I guess my 
next move is to install the devel module and see if I can
find a 
difference between the sql actually being generated when
user=1 vs user!=1.

ps. It was great meeting you all in Vancouver.

-- 
Tao Starbow
Web Architect, CITRIS

Tao Starbow wrote:

> Stop me if you've heard this one before.
>
> I recently upgraded the server running my Drupal site,
and the events 
> calendar stopped working for everyone except user=1.  I
tracked down 
> the problem to this (simplified) line of SQL:
> SELECT n.nid, e.event_start FROM  e INNER JOIN
 n ON 
> n.nid = e.nid
> This returns all my events if the user=1, and zero if
the user is 
> anyone else.
> However, if I rewrite the SQL as:
> SELECT n.nid, e.event_start FROM  n INNER JOIN
 e ON 
> n.nid = e.nid
> then it behaves as I would expect, returning all events
regardless of 
> who the user is.
>
> I did not have this problem on my old server, which was
running mysql 
> 4.0.20-max.  The new server is running mysql 5.0.17.
>

This is not a mysql issue, but a simple bug in event.module.
The 
rewriting of the query fails as it isn't in the form the
regexp expects 
(I did say that using regexps is evil, did I?).
Please file a bug report for event.module so that I don't
forget about 
it. A patch is also appreciated. The reason it doesn't
happen for uid 1 
is that no rewriting takes place for that user.

Cheers,
    Gerhard

On Fri, Feb 10, 2006 at 01:01:12PM -0800, Jonathan Daugherty
wrote:
> # I couldn't find Auth_OpenID_DatabaseConnection
anywhere, which
> # Drupal_OpenID_DBConnection attempts to extend
> 
> Well, I didn't expect anyone to actually try running
the module; it's
> just for viewing and has been developed against an
unreleased version
> of our PHP OpenID library.  I guess
what I am looking for (with
> regard to the code specifically) is "that should
work and is
> acceptable", "don't do that, that's
terribly awful", or "You'e almost
> there, but here are some things to consider." 
But I'll take a test
> run, too, for sure. 

Ah, well, I don't know a lot about Drupal internals
personally, but as
I'm interested in getting OpenID going with it, I thought I
could best
help by trying it out and offering encouragement 
 
> Thanks for the detailed reply, and thanks for going to
the trouble to
> get it to work.  Your decision to extend DB_mysql was
correct.  Check
> to be sure that the openid_* tables are in your Drupal
database.  Did
> you get any kind of error when you return to your site
from the OpenID
> server?  (If you made it that far, things appear to be
in working
> order.)  When you return to your test site, do you get
prompted to
> enter an email address for the new account?  If so,
does that succeed?

Yes, I have three openid_consumer_* tables, settings and
associations
each have one entry (settings has an auth_key, associations
has an entry
with the server_url I used. No error shown, in the logs I
see some
'table already exists' messages, and a 'No colon on line
6:' from
KVForm.php line 77. I did get prompted for an email address,
but no
account with that address is in my users table.

After a bit more investigation it seems that it was a
browser issue.
Konqueror 3.5.1 doesn't like it somehow, but with Firefox
it works OK.
(Except for there being an extra 'openid/' in the
returned-to url, which
I can fix by removing it from the header("Location:
"... line in
openid_return() ).

I'll try looking into the Konqueror problem myself.

~Ainsley

On Sat, Feb 11, 2006 at 02:02:25PM +0000, Ainsley Pereira
wrote:
> After a bit more investigation it seems that it was a
browser issue.
> Konqueror 3.5.1 doesn't like it somehow, but with
Firefox it works OK.
> (Except for there being an extra 'openid/' in the
returned-to url, which
> I can fix by removing it from the
header("Location: "... line in
> openid_return() ).
> 
> I'll try looking into the Konqueror problem myself.

Found it. In openid_email_form(), I changed:

$form['#action'] = url();

to

$form['#action'] = url('openid/get_email');

and it now works in Konqueror and elinks too.

Hope that helps,
Ainsley

Tao Starbow wrote:
> Stop me if you've heard this one before.
> 
> I recently upgraded the server running my Drupal site,
and the events 
> calendar stopped working for everyone except user=1.  I
tracked down the 
> problem to this (simplified) line of SQL:
> SELECT n.nid, e.event_start FROM  e INNER JOIN
 n ON n.nid 
> = e.nid
> This returns all my events if the user=1, and zero if
the user is anyone 
> else.
> However, if I rewrite the SQL as:
> SELECT n.nid, e.event_start FROM  n INNER JOIN
 e ON n.nid 
> = e.nid
> then it behaves as I would expect, returning all events
regardless of 
> who the user is.
> 
> I did not have this problem on my old server, which was
running mysql 
> 4.0.20-max.  The new server is running mysql 5.0.17.
> 
> I suspect whatever is causing this is also at the root
of my 
> node_access_by_role issue (http://drupal.org/node/4
0623).  I guess my 
> next move is to install the devel module and see if I
can find a 
> difference between the sql actually being generated
when user=1 vs user!=1.

If the actual generated SQL works/fails as you describe in
the simplified SQL 
above, I think you have found a bug in MySQL.  INNER JOIN
should be 
commutative, that is, it should not matter which order the
two joined tables 
are listed, the results should be the same.

> Found it. In openid_email_form(), I changed:
>
> $form['#action'] = url();
>
> to
>
> $form['#action'] = url('openid/get_email');

Thanks!  I've applied the fix.

--
  Jonathan Daugherty
  JanRain, Inc.