On Thu, Jul 31, 2008 at 2:12 PM, Allen Gilliland
<[EMAIL PROTECTED]> wrote:
> I don't mean to be difficult, but I'm still not a fan of all the OpenID
> specific methods. The couple things about this proposal which still don't
> seem right to me are ...
No need to apologize. I really appreciate that you took the time to
read and respond to the proposal.
> 1. Why do we need to support multiple OpenID urls per user? Nobody has
> answered that question yet and it seems to me that it's important. It's a
> pretty significant simplification to the implementation if we only support a
> single OpenID url per user account, so unless there is a very specific
> reason we think multiple are required then I don't see why we would do that.
> If it really is necessary then fine, it just seems like a relevant question
> which nobody has answered.
I do not think this is an absolute requirement at all. It is a "nice
to have" feature only.
> 2. The point of the generic support for user attributes was to avoid methods
> like the OpenID specific ones proposed for the UserManager. Those methods
> should be generic methods for user attributes, not OpenID specific, such as
> ...
>
> getUserByAttribute("openid.url", "attribute.value");
> getUser().getAttribute("openid.url");
> getUser().setAttribute("openid.url", "attribute.value");
I agree, that is a much better approach. I don't like having OpenID
specific methods either.
> 3. I don't know why it would be necessary to modify the UIAction class at
> all and even the modifications to the Register class should be non-OpenID
> specific. The way the prepopulating of the Register action should work is
> that *if* the client is known then the result of getAuthenticatedUser()
> should return a User object representing them which can then be used to
> prepopulate the bean used by the action.
I agree here too.
And note, in the latest patch from Tatyana, there is no change to UIAction.
https://issues.apache.org/roller/browse/ROL-1733
I believe there will have to be some OpenID specific things in the
login page, but we I think we can avoid OpenID specific code almost
everywhere else.
> The current Register action implementation isn't quite right yet which is
> why some changes are necessary, but if it was right then there should really
> be no need to modify that code at all. The current code is doing some funky
> usingSSO/fromSSO code which doesn't need to be at that place in the code.
> That code can be pushed up into the RollerSession code so that if the
> client is identifiable via SSO or any other way then we can access a User
> object that represents them.
I'm not sure I understand what you mean here. What logic are
suggesting needs to be moved to RollerSession?
> sorry to be tough, it's just that if we don't do this right on the first
> pass then we'll have to go back and redo it later, which is more work :/
Thanks, this is good feedback.
- Dave
>> Tatyana has updated her OpenID for Roller proposal here:
>> http://cwiki.apache.org/confluence/x/zVAB
