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.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

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

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

OpenID support - last steps

Go to End

6 Posts   1824 Views


Google Summer of Code Hacker, 152 Posts

19 June 2007 at 2:03am

Edited: 19/06/2007 2:03am

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..



Community Member, 58 Posts

19 June 2007 at 8:40am

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.


Administrator, 690 Posts

20 June 2007 at 9:42pm

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.


Google Summer of Code Hacker, 152 Posts

21 June 2007 at 1:59am

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?


Core Development Team, 19 Posts

25 June 2007 at 9:16am

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


Google Summer of Code Hacker, 152 Posts

25 June 2007 at 10:16pm

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 (!?