2012/3/26 Jure Jeseničnik <jure.jesenic...@tsmedia.si>: > First of all I hope that you find my contribution useful. I wish I could have > done more.
Jure, absolutely useful. You had pretty much hammered the federatedaccounts-facebook code to do openid instead and I had changed some things around meanwhile, but I like starting from a functional implementation so I can keep testing it while I refactored it to follow the new form and for general use. Also, your contribution prodded me to actually start working on openid integration now rather than sometime later. > Regarding your questions: > 1) I would definitely like to see as many Id providers as possible or at > least a possibility to add as many as you would like. I'm pretty sure there > will be some users that will have the need to incorporate their own openId > server through the federatedaccounts component. > Yes, I can see that. Mostly I'm wondering if there's a use case for limiting to certain openid providers only. > 2) We do. We're currently using attributes like phone number and more. Ah, I knew it. Depending on the selected openid provider, that information may not be available. Do you not allow those that don't give you the information or you allow/make your users fill them in later? > 3) This part should be very flexible, so the designers could adjust this to > the look & feel of the surrounding application. We, for example would like to > use nothing but 16x16 icon for each supported provider. I would very much > like to achieve this by not having to tweak the tynamo-federatedaccount code > itself. If there was reasonable configurable component federatedaccounts-openid that allows tweaking the ui, would you use that or you'd rather just plug in your own openid UI component, overriding the built-in one? > I like the idea of using multiple openId components in order to achieve any > layout you want. I used this to combine the facebook/twitter components with > various different openId providers. > The situation where arbitrary openId provider used should be implemented with > some sort of adjustable popup with a input field to enter your openId > identity. Similar to a way that previously mentioned stackoverflow is using > but more compact. > Yes, the stackoverflow is a bit convoluted, although fairly comprehensive one. I'll take that as the UI foundation unless anybody can point to a better one. Anybody willing to point me to or collect openid badges to be used in the login component? Many openid providers have made and allow the use of their own logos, but the sizes don't necessarily match up nor confirm to the same style. Kalle > -----Original Message----- > From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] > Sent: Wednesday, March 21, 2012 8:45 PM > To: Tapestry users > Subject: Tynamo Federatedaccounts OpenID module coming up... > > Based on the initial work of Jure Jesenicnik and Borut Bolcina > (http://jira.codehaus.org/browse/TYNAMO-123, thanks guys), I'm currently > working on adding OpenID to the list of Tynamo's federatedaccounts remote > authentication providers. Here's a few questions for those who care about > OpenID: > > 1) Do you typically use or would you like to use only selected OpenID > providers or is it the more, the better? > 2) Do you use attribute extensions - if so, what's important for you? > Names, roles or do you use some specific custom attributes? > 3) I've seen a few different implementations of openID provider selection > panels (i.e. who do you want to authenticate with). Would you like to have > them all listed, should it be drop-down by default? > Can you provide links to existing implementations to show what you'd like and > why? > 4) Do you have or do you foresee a need to customize OpenID authentication > flow or do you want to behave as much the same as possible with any given > provider? > 5) Bonus question for those who've used Guice. openid4java (the underlying > openid consumer implementation we are using at the moment) uses Guice 2.0, > any idea if Guice 2 and Guice 3.0 are at all compatible? Not sure I want to > fork openid4java at this point just to remove the dependency to guice > (although I'm tempted...). > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
