[consulting] "Political" question about single login

[matt j. sorenson]

On 3/31/10 3:40 PM, Audrius Naslenas wrote:
> The idea is to give an option for extra privacy - if on one site user 
> is named "johnsmith" so he could name himself "magician33" on the 
> other, as some of the sites on the network will be with real names 
> revealed on their posts, other - with some privacy, third - only 
> usernames.
maybe this could be accomplished with:

a) custom user profiles - and create all the custom fields needed to 
hold these aliased usernames, etc like:subsite-x_username, 
subsite-y_username

then

b) give each site it's own user profile template in the theme layer, 
showing only the fields you want shown on each respective subsite... or 
possibly alternatively use contemplate to achieve the same (if user 
profiles can be contemplated... I don't know, can they?)

I don't have time to try it, but that might be 1 route to achieving your 
#2 req.

--
matt j. sorenson
>
> ------------------------------------------------------------------------
> *From:* consulting-bounces at drupal.org 
> [mailto:consulting-bounces at drupal.org] *On Behalf Of *matt j. sorenson
> *Sent:* Wednesday, March 31, 2010 8:01 PM
> *To:* consulting at drupal.org
> *Subject:* Re: [consulting] "Political" question about single login
>
> d.o. integrated with g.d.o. using bakery...
>     project: http://drupal.org/project/bakery
>     faq: http://drupal.org/node/567410
>
> with bakery, each user account has 1 user and 1 password... so it 
> probably doesn't account for your #2 wish... what is the 
> motivation/requirement for one (1) login having multiple usernames & 
> profiles?
>
>
> On 3/31/2010 9:37 AM, Jason Smith wrote:
>> domain access is a fantastic module, but it is a far reaching one. 
>> Some things it handles very well, some .... not. It is a really 
>> comprehensive module, but it cannot catch every use case or handle 
>> all third party modules. So if you don't fit in the groove, prepare 
>> for some work. What you are describing is more of a side effect of 
>> domain, not it's central use.
>>
>> It will handle 1. easily enough, but not 2. Personally, I would use 
>> OpenID as it would be more targeted to your needs.
>>
>> On Wed, Mar 31, 2010 at 9:20 AM, sivaji j.g <sivaji2009 at gmail.com 
>> <mailto:sivaji2009 at gmail.com>> wrote:
>>
>>
>>
>>     On Wed, Mar 31, 2010 at 7:40 PM, Audrius Naslenas
>>     <audrius.naslenas at gmail.com <mailto:audrius.naslenas at gmail.com>>
>>     wrote:
>>
>>         What is the best way to make single login solution with:
>>         1. Single and preferably only one login/register place on
>>         "central" site of network
>>         2. Different usernames (display names) and configurable user
>>         profile data on each site
>>
>>         For now, I am not in a rush to sell soul to Facebook Connect,
>>         (well even this module does not have
>>         100% needed features) what are the other viable choices?
>>         Some other LDAP based solution, not even Drupal itself? CAS?
>>         Single Sign On module? OpenID + supporting modules?
>>
>>
>>     Try Domain Access module http://drupal.org/project/domain
>>
>>
>>
>>
>>
>>     -- 
>>     Thanks
>>     Sivaji
>>
>>     _______________________________________________
>>     consulting mailing list
>>     consulting at drupal.org <mailto:consulting at drupal.org>
>>     http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>    
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20100402/3b3da938/attachment.html