mohan-nishit / opendatakit

Automatically exported from code.google.com/p/opendatakit
0 stars 0 forks source link

Odd lockouts when upgrading and/or changing superuser #242

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. multiple siteadmins (user A, user B) configured for a website.
2. website was last updated by user B.
3. update site with user B.
4. user A is locked out (unable to access site at all).

also

1. ditto (1) above
2. website was last updated by user A.
3. update site with user B.
4. user A is locked out (unable to access site at all).
5. also appears that all other users are impacted(!)

user A, B are both Google accounts.

What is the expected output? What do you see instead?

Changing superuser should leave the old superuser as a valid siteAdmin and add 
the new superuser as a siteAdmin.  It shouldn't otherwise alter any permissions.

Original issue reported on code.google.com by mitchellsundt@gmail.com on 25 Jun 2011 at 12:02

GoogleCodeExporter commented 9 years ago
To clarify further, changing superuser did not always cause problem. The 
problem also occurred on upgrade if the super user remained the same. The other 
SiteAdmin could lose their permissions. The checkboxes would look correct but 
the other user could not login without the super user deleting the affected 
account and recreating it. 

Original comment by wbrune...@gmail.com on 27 Jun 2011 at 7:13

GoogleCodeExporter commented 9 years ago
Changeset 
http://code.google.com/p/opendatakit/source/detail?r=81df3ac2d854e17443b7696dc08
99e39fcdff295&name=uiexperiment&repo=aggregate

Addresses most of the problem for single-instance operations.  Still need to do 
further work to make multiple-instance operations better.

Original comment by mitchellsundt@gmail.com on 28 Jun 2011 at 8:00

GoogleCodeExporter commented 9 years ago
Multiple instances of the aggregate server now converge on the same security 
state via each server polling the _security_revisions table to detect if 
another server has changed the security configuration.  As a fail-safe, each 
server also reloads its security configuration every 2 minutes regardless.  The 
polling and refresh are handled when 
RoleHierarchyImpl.getReachableGrantedAuthorities() is called (delaying that 
request and making it incur the database hit).

The changeset is 
http://code.google.com/p/opendatakit/source/detail?r=c2f9d0b7120dfab9b6bd9a8526f
3b0a10cdefa05&name=uiexperiment&repo=aggregate

Original comment by mitchellsundt@gmail.com on 30 Jun 2011 at 10:43

GoogleCodeExporter commented 9 years ago
Verified that this is fixed in the beta 3 candidate

Original comment by mitchellsundt@gmail.com on 16 Jul 2011 at 3:10