incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@me.com>
Subject Re: author ids
Date Sun, 24 Aug 2008 14:21:10 GMT
> I think we should choose UID as an arbitrary string, and choose the  
> initial value of the string to be the login id.  This also protects  
> automatically against anyone who tries to re-register an existing ID.

Does this mean we need to (slightly) refactor the interface for  
UserProfile so that getId() returns a String? It should be the same  
ID, methinks.
>
> This is obvious.  We can have a way better ACL editor...

Agreed. Thought I'd restate the assumption. :)

>> - For those who are curious (Terry?), we already change user names  
>> in ACLs when the person's login/wiki name changes. So if Terry  
>> decides to change his wiki name from TerryS to Terry, all ACLs that  
>> contain "TerryS" will be chanced correctly.
>
> This is obviously not good, because it will cause changes in all  
> pages, even though it was something else which changed.


Well, this is something we do today, already. And the reason we do it  
is because otherwise if a user changed their wiki name, all of sudden  
he or she would be locked out of all pages containing ACLs with their  
name.

So, when a user changes his or her name, UserManager fires a  
PROFILE_NAME_CHANGED event. PageManager detects this, iterates through  
every page and checks the ACLs for any of the "old" names. If any are  
found, the ACL is changed and replaced, and the page is saved.

This particular chunk of code would go away, clearly, if we stored IDs  
rather than Principal names. However, the ACL implementations would  
need to resolve the ID and return Principals (do the "translation"  
between IDs and Principals).

(Just trying to think this through...) 

Mime
View raw message