Hey, thanks for testing it out... a lot of question :-)

@Sigurd:

No, I don't have SVN access to the forum module

"Who can edit this?" is supposed to work (I added now also a Permission check for "CMS_ACCESS_CMSMain" so logged in forum members don't have access)

I changed the labels now (r37571).

@Sam:

Of course you couldn't login. You are not a registered member. If everyone with an OpenID URL could login would be a big security hole!
I added you now to the Administrator group so you can log in now with your OpenID account.

Yes, I know :-) But I didn't know how to call it because email is not always an email :-) I changed it to "Email & Password", maybe we should discuss that at some point.. I think in Email should really be a valid email address..

@Romain:

Well, that's a little problem :-) I don't know exactly how it should behave in that situation, but I think that shouldn't be a problem.
If someone can edit the content he has already all the "destructive" rights, so it doesn't really matter if he can also change the view access level (if he wants to restrict it, he could simple delete the whole content so that you get an empty page).

But we definitively should discuss those situations.

The process for new OpenID users getting access to the site seems a bit backwards. I would have thought it should go:

* New OpenID user asks for access
* They are told that their access needs to be approved; an email is send to the site administrators
* One of those administrators approves the access; an email is send to the original applicant.
* They can now access the site.

The use-case of using OpenID to log into the CMS is pretty rare; it's going to be much more commonly used in situations such as forum commenting or access to restricted content, where "on-site registration" would be the norm.

Well, I don't agree on that. I think the most common use case of OpenID will be for example a site administrator that runs dozens of sites and doesn't want to store a different *clear text* password (as it is by default at the moment) on every of his sites.

I'm just thinking about a company like SilverStripe :-) You run dozens of sites and obviously you have an administrator account on each of them. Since other (administrator) users can look at your password you have to choose a different one for every site. I would be a great advantage to just have *one* OpenID account for all of those sites that you can use without ever storing any password in any of those sites.
You can even set you up an internal OpenID server so that your password never goes out of house...

I know that the current situation where we abuse the email field is not the optimal solution and therefore I planned to implement an OpenIDAuthenticatedRole decorator like the new ForumRole. I mailed you about that already last Thursday asking you for the new code that adds support for those new decorators (http://doc.silverstripe.com/doku.php?id=member&s=member).

Fair point on the multiple-site-admin thing. But I do think that we do need better handling of other security situations.

Perhaps, the Security/login error message should say something along the lines of:

"Your OpenID account hasn't been added in our system yet. <a>Click here to request access from the site administrators</a>"

And we can add some OpenID request system to deal with this. The system would need some way of knowing which security group to add you to - and there might be more than one group on any given site. **That** could get a bit tricky - the system would need to know what level of access the user was needing.

I'll get you that Role decorator code in the next day or 2.

The other thing with OpenID is that it seems you put in your OpenID address instead of an email address. Or am I mistaken?

Would it not be better to add a new field, labelled "OpenID URL", meaning I can either login as sigurd@silverstripe.com with a password OR an openid URL.

Secondly, I suggest that not everyone is interested in having OpenID support, and that you might have a method, placed in _config.php by default like

someObject->enableOpenIDSupport();

which;
a) makes the login form show openid support
b) allows the openid support
c) shows the openid field in the CMS

I agree with Sam that having the error message say something like "Your OpenID account doesn't have access to login to this CMS" or something, however I wouldn't spend too much time on the request system until you feel you've got most of your other essential work done :)

@Sam

> But I do think that we do need better handling of other security situations.

Of which specific situations are you thinking?

Why do you want to use a special "request system" for OpenID? I think of OpenID just as another way to express his own credentials, another way to pass a user name and a password to a system. That would be the same as if someone logs in with an unknown user name and you would ask him if he wants to request access from site administrators..

I think that's just unneeded overhead that makes everything unnecessarily complicated. In any *normal* situation you know your editors or at least they know you and can simple write you a mail and you create them then an user account.

What would you do if let’s say "bigted795.myopenid.com" requests access to the page? Normally you don't know his OpenID and you don't even have his email address (if he didn't make it public available - which is rather improbable).

> I'll get you that Role decorator code in the next day or 2.

Perfect! Thanks a lot

@Sig

Yes, but only at the moment. That's the decorator thing that I was talking about. I'll add a decorator class that adds an OpenID field to the member table which I then can use for this.

We started to discuss the support of both login methods at the same time some time ago but without any real result. Maybe we should fix it now here.

Should a user be able to login with his email & password AND OpenID at the same time or just with one method?
The thing that makes it preferable to just use one method is due to security concerns. If someone normally uses OpenID he probably will use a *really* easy (member-)password (which he obviously won't ever change) and there is a bigger attack surface. On the other side, the email & password system could be used as a fallback system if the OpenID server is offline.

> someObject->enableOpenIDSupport();

That exists already :-) In sapphire/_config.php it's possible to enable/disable the different authentication methods:

Authenticator::registerAuthenticator('OpenIDAuthenticator');

I would say allow both methods to login as a particular user. This means, for instnace, with logging into a forum, that you dont have two users for the same forum, etc.

I'm going to assume its the more tech savvy who will use openid and they will be savvy enough to be diligent with their passwords.

PS: cool about the registerAuthenticator, glad to see this