You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2008/07/31 14:25:50 UTC
Roller / OpenID proposal updated
Just a heads-up...
Tatyana has updated her OpenID for Roller proposal here:
http://cwiki.apache.org/confluence/x/zVAB
Feedback is welcome.
- Dave
Re: Roller / OpenID proposal updated
Posted by Allen Gilliland <Al...@Sun.COM>.
Dave wrote:
> On Thu, Jul 31, 2008 at 2:12 PM, Allen Gilliland
> <Al...@sun.com> 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.
If it's not required then I would opt for the easy route and just
support a single OpenID per user.
>
>
>> 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.
Yeah, that sounds right to me. You'll definitely need some changes to
the Login struts2 action and jsp.
>
>
>> 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?
in Register.execute(), the try/catch block which looks for a User object
via CustomUserRegistery.
That block should be replaced with a simple bit of code like ...
if(getAuthenticatedUser() != null) {
getBean().copyFrom(getAuthenticatedUser());
}
For that to work we need to ensure that UIAction.getAuthenticatedUser()
returns a valid User object in all cases where the client is authentic,
not just in cases where the client has a local session.
This is effectively the same situation I ran into when doing comment
authentication. We need to support the notion that a client can be
authentic even if they don't have a local session and aren't directly
part of the local Roller db.
We already do the right thing in the UIActionInterceptor, which means we
should have the authenticated User object available to all s2 actions ...
RollerSession rses = RollerSession.getRollerSession(request);
if(rses != null) {
theAction.setAuthenticatedUser(rses.getAuthenticatedUser());
}
So really all we need to do is move that original bit of code that is in
the try/catch block of the Register.execute() method and move it into
the RollerSession code so that when you are trying to get a User from
RollerSession it automatically consults SSO.
-- Allen
>
>
>> 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
Re: Roller - OpenID
Posted by "Tatyana V. Tokareva" <to...@cs.vsu.ru>.
Hello,
I've created a new patch, which allows Roller to support OpenID login and
registration using simple registration extension. It is available here:
https://issues.apache.org/roller/browse/ROL-1733
Your feedback is very welcome!
Best regards,
Tatyana
Re: Roller - OpenID
Posted by Dave <sn...@gmail.com>.
On Sun, Aug 10, 2008 at 5:12 PM, Tatyana V. Tokareva <to...@cs.vsu.ru> wrote:
>> > Also maybe it will be better to put user attributes list in some kind of
>> > properties file. (right now this list is stored as an enumeration)
>>
>> I don't think we need to have a fixed list of property names,
>> so I guess I don't think we need an enumeration or property.
>
> This question is still actual for me.
> Will it be better to add another one database table
> to define all attribute names or just hardcode them?
I missed this question eariler: I would simply define "public static
final ..." fields for each attribute name you use.
How are you doing with your latest patch? I believe we have a
dead-line coming up.
- Dave
Re: Roller - OpenID
Posted by "Tatyana V. Tokareva" <to...@cs.vsu.ru>.
Hi Dave,
I've managed to make fields prefilling with user SREG attributes on the user
registration page.
I'm going to tide up code a little bit, test it and create a new patch in a
couple of days.
There are also some comments below.
Best regards,
Tatyana
On Sun, 10 Aug 2008 00:46:01 -0400
Dave <sn...@gmail.com> wrote:
> On Tue, Aug 5, 2008 at 7:32 AM, Tatyana V. Tokareva <to...@cs.vsu.ru>
> wrote:
> > I've uploaded a second Roller-OpenID patch to the JIRA
> > https://issues.apache.org/roller/browse/ROL-1733
>
> Hi Tatyana,
>
> I reviewed the code yesterday, tried it out and my comments are below.
>
>
> > Here is the description of what has been done so far:
> > I've managed to make openid url an editable option for user.
> > I've also accounted of comments to the previous patch and made some
> changes
> > in the code.
>
> And you're using generic user attributes for storing each user's
> OpenID URI and have no OpenID specific methods, which is good.
>
> Here are a couple of comments about the new UI elements that you've added:
>
> - The OpenID user fields do not allow enough characters for a URL
> Make it size="40" maxlength="255"
>
> - The help text does not explain what to enter in the field, maybe
> this is better:
> "Your OpenID username in the form of a URL (optional)"
>
> - The OpenID UI elements should only be shown when OpenID is enabled
> Add a property to roller.properties so OpenID can be enabled/disabled:
>
> # Enable/disable OpenID (requires Spring Security, will not work with
> CMA)
> authentication.openid.enabled = false
>
> - The login page layout could use some work, but we can take care
> of that later.
I've made openid fields enabling/disabling and fixed fields sizes
>
>
> > When the new user is logging via openID url after successful login on the
> > provider's website he is redirected to the registration page (I had to
> > specify exception mappings in the security.xml to make it work) I want to
> > prefill fields on this page with data, retrieved from the openid provider
> > with help of Simple Registration Extension. It is not supported
> officially
> > in the spring security library yet, so I had to made it by myself.
> > By this moment they've created a patch in response to my issue ( jira
> > http://jira.springframework.org/browse/SEC-935 ) and I've switched to an
> > official version, but I had to change code a little bit to make the
> library
> > it working.
>
> I don't understand this part. Do we need new Spring Security jars to
> make the patch work? Or, is the new schema file enough?
>
Firstly, you need a spring-security-openid library, which is attached to the
issue.
I've made a new one with the help of official patch from
http://jira.springframework.org/browse/SEC-935
The patch allows to retrive Simple Registration Extension user attributes.
The schema file includes openid filter defenition and will be located on the
spring security web site by the next release, but just for now you need to
use a local copy.
You should specify file path in the security.xml
>
> > User attributes are saved in the OpenIDAuthenticationToken as a
> > User object and it's method getPrincipal() returns this object.
> > Right now I'm trying to find a way how to retrieve this object in the
> > Register action to prefill fields.
> > Could someone suggest the right approach?
>
> I don't know enough about OpenID4Java to make a suggestion here.
>
>
> > I also had to put an openid-specific code into the RollerSession - I
> can't
> > make up my mind right now how to get rid of it.
> > Also maybe it will be better to put user attributes list in some kind of
> > properties file. (right now this list is stored as an enumeration)
>
> I don't think we need to have a fixed list of property names,
> so I guess I don't think we need an enumeration or property.
>
This question is still actual for me.
Will it be better to add another one database table
to define all attribute names or just hardcode them?
>
> > Note if you are gonna use the patch you'll need to change the schema file
> > reference in the security.xml
> > ( http://jira.springframework.org/browse/SEC-927 )
>
> I tried that, but I'm running in to a problem on OpenID login
> I see this in the roller.log file.
>
> INFO 2008-08-09 23:04:11,792 HtmlResolver:discover - HTML discovery
> succeeded on: http://rollerweblogger.org/roller
> INFO 2008-08-09 23:04:11,793 Discovery:discover - Discovered 1 OpenID
> endpoints.
> INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Trying to
> associate with http://openid.claimid.com/server attempts left: 4
> INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Found an
> existing association.
> INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Trying to
> associate with http://openid.claimid.com/server attempts left: 4
> INFO 2008-08-09 23:04:11,795 ConsumerManager:associate - Found an
> existing association.
> INFO 2008-08-09 23:04:11,795 ConsumerManager:authenticate - Creating
> authentication request for OP-endpoint:
> http://openid.claimid.com/server claimedID:
> http://rollerweblogger.org/roller/ OP-specific ID:
> http://openid.claimid.com/snoopdave
> INFO 2008-08-09 23:04:11,796 RealmVerifier:match - Return URL:
> http://localhost:8080/roller/roller_j_openid_security_check matches
> realm: http://localhost:8080/roller/roller_j_openid_security_check
> ERROR 2008-08-09 23:04:11,806 RealmVerifier:validate - Discovery
> failed on realm:
> http://localhost:8080/roller/roller_j_openid_security_check
> org.openid4java.discovery.yadis.YadisException: 1798: GET failed on
> http://localhost:8080/roller/roller_j_openid_security_check
> at
>
org.openid4java.discovery.yadis.YadisResolver.getXrds(YadisResolver.java:295)
> at
>
org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:251)
> ...
> ERROR 2008-08-09 23:04:11,807
> OpenIDAuthenticationProcessingFilter:determineFailureUrl
> - Unable to consume claimedIdentity [http://rollerweblogger.org/roller]
> org.springframework.security.ui.openid.OpenIDConsumerException: Error
> processing ConumerManager authentication
> at
>
org.springframework.security.ui.openid.consumers.OpenID4JavaConsumer.beginConsumption(OpenID4JavaConsumer.java:83)
> at
>
org.springframework.security.ui.openid.OpenIDAuthenticationProcessingFilter.determineFailureUrl(OpenIDAuthenticationProcessingFilter.java:107)
> ...
> Caused by: org.openid4java.message.MessageException: 769: Realm
> verification failed for:
> http://localhost:8080/roller/roller_j_openid_security_check
> at org.openid4java.message.AuthRequest.validate(AuthRequest.java:358)
> at
> org.openid4java.message.AuthRequest.createAuthRequest(AuthRequest.java:101)
> at
>
org.openid4java.consumer.ConsumerManager.authenticate(ConsumerManager.java:1000)
> at
>
org.openid4java.consumer.ConsumerManager.authenticate(ConsumerManager.java:937)
> at
>
org.springframework.security.ui.openid.consumers.OpenID4JavaConsumer.beginConsumption(OpenID4JavaConsumer.java:81)
> ... 35 more
>
> Could this be becuase I do not have the right Spring jars?
I can also attach openid specific libraries that I'm using now.
Actually, I've tried logging via my claimid account and I didn't meet any
problems.
>
> - Dave
Re: Roller - OpenID
Posted by Dave <sn...@gmail.com>.
On Tue, Aug 5, 2008 at 7:32 AM, Tatyana V. Tokareva <to...@cs.vsu.ru> wrote:
> I've uploaded a second Roller-OpenID patch to the JIRA
> https://issues.apache.org/roller/browse/ROL-1733
Hi Tatyana,
I reviewed the code yesterday, tried it out and my comments are below.
> Here is the description of what has been done so far:
> I've managed to make openid url an editable option for user.
> I've also accounted of comments to the previous patch and made some changes
> in the code.
And you're using generic user attributes for storing each user's
OpenID URI and have no OpenID specific methods, which is good.
Here are a couple of comments about the new UI elements that you've added:
- The OpenID user fields do not allow enough characters for a URL
Make it size="40" maxlength="255"
- The help text does not explain what to enter in the field, maybe
this is better:
"Your OpenID username in the form of a URL (optional)"
- The OpenID UI elements should only be shown when OpenID is enabled
Add a property to roller.properties so OpenID can be enabled/disabled:
# Enable/disable OpenID (requires Spring Security, will not work with CMA)
authentication.openid.enabled = false
- The login page layout could use some work, but we can take care
of that later.
> When the new user is logging via openID url after successful login on the
> provider's website he is redirected to the registration page (I had to
> specify exception mappings in the security.xml to make it work) I want to
> prefill fields on this page with data, retrieved from the openid provider
> with help of Simple Registration Extension. It is not supported officially
> in the spring security library yet, so I had to made it by myself.
> By this moment they've created a patch in response to my issue ( jira
> http://jira.springframework.org/browse/SEC-935 ) and I've switched to an
> official version, but I had to change code a little bit to make the library
> it working.
I don't understand this part. Do we need new Spring Security jars to
make the patch work? Or, is the new schema file enough?
> User attributes are saved in the OpenIDAuthenticationToken as a
> User object and it's method getPrincipal() returns this object.
> Right now I'm trying to find a way how to retrieve this object in the
> Register action to prefill fields.
> Could someone suggest the right approach?
I don't know enough about OpenID4Java to make a suggestion here.
> I also had to put an openid-specific code into the RollerSession - I can't
> make up my mind right now how to get rid of it.
> Also maybe it will be better to put user attributes list in some kind of
> properties file. (right now this list is stored as an enumeration)
I don't think we need to have a fixed list of property names,
so I guess I don't think we need an enumeration or property.
> Note if you are gonna use the patch you'll need to change the schema file
> reference in the security.xml
> ( http://jira.springframework.org/browse/SEC-927 )
I tried that, but I'm running in to a problem on OpenID login
I see this in the roller.log file.
INFO 2008-08-09 23:04:11,792 HtmlResolver:discover - HTML discovery
succeeded on: http://rollerweblogger.org/roller
INFO 2008-08-09 23:04:11,793 Discovery:discover - Discovered 1 OpenID
endpoints.
INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Trying to
associate with http://openid.claimid.com/server attempts left: 4
INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Found an
existing association.
INFO 2008-08-09 23:04:11,794 ConsumerManager:associate - Trying to
associate with http://openid.claimid.com/server attempts left: 4
INFO 2008-08-09 23:04:11,795 ConsumerManager:associate - Found an
existing association.
INFO 2008-08-09 23:04:11,795 ConsumerManager:authenticate - Creating
authentication request for OP-endpoint:
http://openid.claimid.com/server claimedID:
http://rollerweblogger.org/roller/ OP-specific ID:
http://openid.claimid.com/snoopdave
INFO 2008-08-09 23:04:11,796 RealmVerifier:match - Return URL:
http://localhost:8080/roller/roller_j_openid_security_check matches
realm: http://localhost:8080/roller/roller_j_openid_security_check
ERROR 2008-08-09 23:04:11,806 RealmVerifier:validate - Discovery
failed on realm:
http://localhost:8080/roller/roller_j_openid_security_check
org.openid4java.discovery.yadis.YadisException: 1798: GET failed on
http://localhost:8080/roller/roller_j_openid_security_check
at org.openid4java.discovery.yadis.YadisResolver.getXrds(YadisResolver.java:295)
at org.openid4java.discovery.yadis.YadisResolver.discover(YadisResolver.java:251)
...
ERROR 2008-08-09 23:04:11,807
OpenIDAuthenticationProcessingFilter:determineFailureUrl
- Unable to consume claimedIdentity [http://rollerweblogger.org/roller]
org.springframework.security.ui.openid.OpenIDConsumerException: Error
processing ConumerManager authentication
at org.springframework.security.ui.openid.consumers.OpenID4JavaConsumer.beginConsumption(OpenID4JavaConsumer.java:83)
at org.springframework.security.ui.openid.OpenIDAuthenticationProcessingFilter.determineFailureUrl(OpenIDAuthenticationProcessingFilter.java:107)
...
Caused by: org.openid4java.message.MessageException: 769: Realm
verification failed for:
http://localhost:8080/roller/roller_j_openid_security_check
at org.openid4java.message.AuthRequest.validate(AuthRequest.java:358)
at org.openid4java.message.AuthRequest.createAuthRequest(AuthRequest.java:101)
at org.openid4java.consumer.ConsumerManager.authenticate(ConsumerManager.java:1000)
at org.openid4java.consumer.ConsumerManager.authenticate(ConsumerManager.java:937)
at org.springframework.security.ui.openid.consumers.OpenID4JavaConsumer.beginConsumption(OpenID4JavaConsumer.java:81)
... 35 more
Could this be becuase I do not have the right Spring jars?
- Dave
Re: Roller - OpenID
Posted by Dave <sn...@gmail.com>.
Great! I'm pretty busy today, but I'll try to take a look this evening.
Thanks,
Dave
On Tue, Aug 5, 2008 at 7:32 AM, Tatyana V. Tokareva <to...@cs.vsu.ru> wrote:
> Hello,
>
> I've uploaded a second Roller-OpenID patch to the JIRA
> https://issues.apache.org/roller/browse/ROL-1733
>
> Here is the description of what has been done so far:
>
> I've managed to make openid url an editable option for user.
> I've also accounted of comments to the previous patch and made some changes
> in the code.
>
> When the new user is logging via openID url after successful login on the
> provider's website he is redirected to the registration page (I had to
> specify exception mappings in the security.xml to make it work) I want to
> prefill fields on this page with data, retrieved from the openid provider
> with help of Simple Registration Extension.
> It is not supported officially in the spring security library yet, so I had
> to made it by myself.
> By this moment they've created a patch in response to my issue ( jira
> http://jira.springframework.org/browse/SEC-935 ) and I've switched to an
> official version, but I had to change code a little bit to make the library
> it working. User attributes are saved in the OpenIDAuthenticationToken as a
> User object and it's method getPrincipal() returns this object.
> Right now I'm trying to find a way how to retrieve this object in the
> Register action to prefill fields.
> Could someone suggest the right approach?
>
> I also had to put an openid-specific code into the RollerSession - I can't
> make up my mind right now how to get rid of it.
> Also maybe it will be better to put user attributes list in some kind of
> properties file. (right now this list is stored as an enumeration)
>
> Note if you are gonna use the patch you'll need to change the schema file
> reference in the security.xml
> ( http://jira.springframework.org/browse/SEC-927 )
>
> Your feedback is welcome!
>
> Tatyana
>
Roller - OpenID
Posted by "Tatyana V. Tokareva" <to...@cs.vsu.ru>.
Hello,
I've uploaded a second Roller-OpenID patch to the JIRA
https://issues.apache.org/roller/browse/ROL-1733
Here is the description of what has been done so far:
I've managed to make openid url an editable option for user.
I've also accounted of comments to the previous patch and made some changes
in the code.
When the new user is logging via openID url after successful login on the
provider's website he is redirected to the registration page (I had to
specify exception mappings in the security.xml to make it work) I want to
prefill fields on this page with data, retrieved from the openid provider
with help of Simple Registration Extension.
It is not supported officially in the spring security library yet, so I had
to made it by myself.
By this moment they've created a patch in response to my issue ( jira
http://jira.springframework.org/browse/SEC-935 ) and I've switched to an
official version, but I had to change code a little bit to make the library
it working. User attributes are saved in the OpenIDAuthenticationToken as a
User object and it's method getPrincipal() returns this object.
Right now I'm trying to find a way how to retrieve this object in the
Register action to prefill fields.
Could someone suggest the right approach?
I also had to put an openid-specific code into the RollerSession - I can't
make up my mind right now how to get rid of it.
Also maybe it will be better to put user attributes list in some kind of
properties file. (right now this list is stored as an enumeration)
Note if you are gonna use the patch you'll need to change the schema file
reference in the security.xml
( http://jira.springframework.org/browse/SEC-927 )
Your feedback is welcome!
Tatyana
Re: Roller / OpenID proposal updated
Posted by Dave <sn...@gmail.com>.
On Thu, Jul 31, 2008 at 2:12 PM, Allen Gilliland
<Al...@sun.com> 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
Re: Roller / OpenID proposal updated
Posted by Allen Gilliland <Al...@Sun.COM>.
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 ...
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.
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");
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.
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.
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 :/
-- Allen
Dave wrote:
> Just a heads-up...
>
> Tatyana has updated her OpenID for Roller proposal here:
> http://cwiki.apache.org/confluence/x/zVAB
>
> Feedback is welcome.
>
> - Dave