Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.


Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, biapar, Willr, Ingo, simon_w

OpenID support - last steps


6 Posts   1581 Views


19 June 2007 at 2:03am (Last edited: 19 June 2007 2:03am), Google Summer of Code Hacker, 152 Posts

I'm implementing the last things for full OpenID/i-names support right now, but I have a few questions that I wanted to clarify with you first:

-- Registration --
How should a member registrate his OpenID URL/i-name? Simple use the email field and leave the password blank?

My idea is to create a OpenIDMember class (extends Member) that stores all the OpenID URL in a new table. But the problem then is how should such a member be created from the backend? Create a new button "Add OpenID member"?

What when I edit such a member? How can I modify the displayed form? It seems that the "getCMSFields()" won't be used at all!?

-- Database Integration --
To prevent attacks (namely replay attacks) I need to store some information somewhere. It would be simple if I can just use SQL statements for that without using the DataObject stuff, but I'm not sure if that's a good idea? What about database abstraction? I can post the code here or somewhere if you want.. Postgre, MySQL, SQLite are supported as well as file based storage..



19 June 2007 at 8:40am Google Summer of Code Hacker, 58 Posts

Personal opinion (hopefully generally true) on the database issue:

Using DataObject should be the preferred method to communicate with the database (and it will make my part easier ;) ).
However if that is not possible, DB::query will always be available (as a back-up solution if something is not feasible otherwise), but as it works with raw SQL it makes portability to different databases harder.


20 June 2007 at 9:42pm Administrator, 685 Posts

Markus - we're currently developing some code that can be used to add "extension plug-ins" to the member table, which will let you add columsn to it if you have the openid module included.

It will need to be merged over to the gsoc branhc. I'll post more details ASAP.


21 June 2007 at 1:59am Google Summer of Code Hacker, 152 Posts

Something like a decorator? That would be nice because otherwise we probably get problems since PHP supports only single inheritance and so the combination of different member types and authentication methods will get tricky.

I hope there is a way to override also the edit form. At the moment I created a new class OpenIDMember extends Member with a method getCMSFields(), but the backend still displays the same form for all type of members (also for members created with the forum module).

What do you think about using the email column only for email addresses (valid ones) and adding another column “username” which is then used for the “normal” members as username? Or – my favorite option – leave everything as it is, but require a valid email address as username?


25 June 2007 at 9:16am Core Development Team, 19 Posts

Along with the additions Sam mentioned, there is now support in the member section of the CMS for the custom CMS fields.


25 June 2007 at 10:16pm Google Summer of Code Hacker, 152 Posts

Really? Where? At least in the GSoC branch it's still not supported.

As Hayden wrote me the ForumRole class should be ready, but I can't find it in the daily builds and unfortunately I have not enough rights to access the forum repository (svn:// even if I should (!?