Luke Tucker ha scritto: > Hey, > > On my branch of geonode here: http://github.com/ltucker/geonode there is > some backing for this -- it adds the url /data/acls that outputs json as > described in: > > http://atlas.openplans.org/~dwinslow/geonode-spec/spec/technical/geonode-core/geoserver/permissions.html > > > User administration is just standard django administration, so django > docs may be helpful. You can create a django admin user via: > > django-admin createsuperuser --settings=capra.settings > > and then visit /admin in GeoNode to add other Users. To make Layers > appear in the security json, you'll need to add UserRowLevelPermissions > that relate some User, some Layer and some layer Permission (like maps | > layer | view ), this can also be done in the django admin. Both of these > can also easily be done via python if needed in tests.
Cool. Not sure we want to actually do some built-time testing that requires GeoNode to be running, but I'll keep that in mind. > I tossed in an 'is_superuser' and 'is_anonymous' flag into the json > structure. Currently superuser is related to the is_superuser flag on > the django User object, but it's unclear to me whether that is what we > mean by it -- should be enough for testing though. An admin's list of > ro and rw layers currently only includes explicitly created permissions. The administrator is GeoServer is omnipotent, can do anything, so there is no need for a list of layers there. I played with the django administration and managed to get some ro layers pop up in the json output by adding the "can view" permission on the layer to the desired user, and it seems that to get rw I need to add both "view" and "change" (sounds a bit odd to me, writing does not imply reading?) > As specified, you can use HTTP basic auth or pass along a django > sessionid cookie -- currently http basic auth takes precedence for a > given request if both are present. You can quickly poke the django > endpoint using something like: > > curl --user admin:admin http://localhost:8000/data/acls Cool. The only thing I don't get at the moment is the name of the shared cookie. I guess I could get away by just throwing all cookies back to GeoNode... Anyways, if I look for cookies coming from localhost I get: csrftoken (uh? cross site request forgery?) sessionid (which sounds like the tomcat session tracking cookie) ACEGI_SECURITY_HASHED_REMEMBER_ME (the name says it all) wicket-modal-window-positions (same as above) > I'm not sure what your hours are like, but if you catch me (ltucker) in > irc on #geonode I can help get you set up / troubleshoot and figure out > if anything you need is missing. I live in Italy so I'm 6 hours ahead of you, but I'm usually online until evening (7-8pm depending on the day): http://www.timeanddate.com/worldclock/meetingtime.html?day=14&month=7&year=2010&p1=215&p2=179&p3=-1&p4=-1 Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers.
