This is an initial port of openid_provider to Drupal 7 API.
Since this is my first attempt at writing code for Drupal, do not expect much.
I have tested as best as I could, and it seems to work, but this does not say much.
use at your own risk!

My approach was to first pass the code through coder-upgrade process, which fixed
most but not all of the API changes. Impressive piece of functionality!

Then, I started running the module, and fixing errors. At some point, I discovered
that pathauto had its own implementation of hooks for core objects, like user, and
I threw away some of the code and shamelessly replaced it with a modified copy of the
equivalent routines from pathauto. This worked like a charm, so pathauto integration
now seems to work flawlessly. in fact, in the process, I found a bug in pathauto itself!
(fixed in the latest dev version).

I am not submitting this as a patch, first because I am not sure how the process works,
and second, this is not really my work, so I shouldn't claim responsibility for it :)

I would ask the original author, which seems to be following this issue, to review the
changes (too many to report here, use a source diff, I use Beyond Compare and highly
recommend it), and if satisfied, submit it as a 7.x version. Meanwhile, I am putting it
in production, since I need it *now*. If no version appears within the next month, I will
try to update this issue with new bugs I find and fix.

One thing needs to be implemented still, which is really a cosmetic change :
In D7, it seems that the administrator by default gets their form appear in an overlay.
I, of course, have no idea how to do this, since I have never written a form for Drupal,
so this is something that the author needs to fix, if he wants. It affects the "Open ID sites"
tab of the User Account View.

Note to the author : Apart from porting the code, I have made a couple of functionality
changes :

1. I needed the user id (uid) as part of the authentication response, so I added a custom
field, 'openid.x_mk_id'. it should not affect anything, so please leave it there, somebody
else may need it. The reason I need it is that I am integrating an external application,
which will use the drupal user database instead of itss own, and needs a non-alpha primary
key for the users.

2. When I was initially testing with Drupal 6 (non-modifed code), I had problems authenticating.
my investigation of the issues showed the following :

It seems that the OpenID spec allows, bit does *not* require an association to be established
before an authentication call is made. However, the original v6 code assumed that all calls
went through an association workflow. This is simply not true. For example, 3 of the open source
php clients (RPs) I tried (SimpleOpenId, LightOpenId, and I dont remember the other) do NOT do this,
and as a result fail. I noticed in Google that other people had the same problem (look for assoc_handle).

So, I modified the code not to assume this, and to work even when an association does not exist.
If it does, it will work as before. so, nothing is lost, and compatibility with naughty clients is
much better. IMHO, you should *keep* this change. I know I will, in my local copy...

I am aware that authentication without an association is less secure, but since that is what my client does
I will have to live with it, for now. And, as I said, this does not compromise the "normal" way the code
worked before.

That's it, enjoy!

Mike Cariotoglou
29-March-2011
