incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: Logged in as multiple users, how should application deal with this new feature?
Date Thu, 19 May 2011 14:52:49 GMT
On Thu, May 19, 2011 at 4:15 PM, Henry Story <> wrote:
> On 19 May 2011, at 14:36, Reto Bachmann-Gmuer wrote:
>> Hello
>> I've noticed that with the change to principals one can be logged in
>> as multiple users.
> To be precise the changes made use of the flexibility of Java's Subject class.
> The subject class is designed to allow one to have multiple Principals.

We shouldn't do things just because its possible, we should only
implementing things with a beneficial addition to useful possibilities
in relation to the added complexity
> So this is not that different from Foaf. We can have multiple identifiers: social security
number, webid, username... These are all inverse functional properties.

That's not as its currently implemented by your code, if one logs in
with multiple webids (and the maybe additionally with cookie login)
multiple users are created in the system graphs

>> How are applications supposed to deal with this? In
>> my wall-applcation and blogging engine I assumes a request originating
>> from exactly one user (which can be user anonymous). I know wanted to
>> updated my apps and was wondering how to do this.
> What we need is to improve the ways to identify the user so that he can log in
> various ways (including openid in the future or facebook connect).
> I think we should do the following. Currently the user is identified in the
> graph <http://tpf.localhost/system.graph>
> @prefix perm: <> .
> @prefix zz: <> .
> @prefix foaf: <> .
> </user/admin/profile#me>
>    perm:hasPermission [
>        perm:javaPermissionEntry "( \"\" \"\")"
>    ] ;
>    perm:passwordSha1 "d033e22ae348aeb5660fc2140aec35850c4da997" ;
>    zz:lastLogin "2011-05-17T18:03:48.558Z"^^<>
>    zz:userName "admin" ;
>    a foaf:Agent ;
>    foaf:mbox <> .
> so here the user has already two identities
>  - the WebID </user/admin/profile#me>
>  - the zz:userName "admin"
yes, but we used to have just one resource, we now potentially have
multiple resources created by the foafssl login module.

> It would be easy to extend this to allow openid by adding the relation
> </user/admin/profile#me> foaf:openid <> .
> The principal can therefore be either:
>  - the webid
>  - the openid
>  - the account name ("admin", "joe",...)
>  - facebook account, ...
> it does not matter.
> What we should do is to create subclasses of Principal (which anyway is just an interface)
> to allow one to distinguish these different types of principals.
> Each principal can then be used to get the resource (bnode or uri) that is the
> foaf:Agent, and the zz:userName should be shown if it exists, or some
> zz:preferredUserName, which could be set automatically.
>> The same difficulty occurs with the displayed username in the menu,
>> and where the menu-item "control-panel" shall point to.
> It should point to the home page, as now.
yes, but what is the "home page" if one can log in as more than one
user simultaneously?

> If there are two non fused identities, the user should be asked if he wants to fuse them,
and which he prefers to have as his new home. I suppose one could also give him the opportunity
to log in as one or the other, by changing a menu.

seems a great increase of complexity, what legimitates this? Talking
about certs with multiple webids in the specificatioon group is one
thing, making thing complex to support this (imho quite exotic)
feature is another.
> There is also  CLEREZZA-515 "ugly account name when logging into ZZ with a foreign WebID"
> though this would be just as valid for OpenIDs.
I don't think this relates two my question, having more than one user
logged in is difficult both with nice and with ugly account names.
> I can work on the core auth code change if someone can help me with the UI piece from

So the short answer to my question "How are applications supposed to
deal with this?" is "you currently can take a user randomly or let the
user choose who he wants to be, but in future thing might go back
again to one user, as this is handled like inverse functional
poperties in foaf"

> Henry
>> Reto
> Social Web Architect

View raw message