Re: [geonode] GeoServer/GeoNode security integration: where's the
python api?
- From:
- Luke Tucker
- Date:
- 2010-07-13 @ 21:37
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.
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.
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
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.
Hope it helps,
- Luke
On Tue, Jul 13, 2010 at 2:52 PM, Andrea Aime <aaime@opengeo.org> wrote:
> Hi,
> as you may know I'm working on the GEoSErver/GeoNode security integration.
>
> At the moment I have the pieces needed for integration written
> and lightly tested here:
> http://github.com/aaime/geonode/tree/security
> (btw, reviews and comments welcomed)
>
> By tested I mean that the whole system is based on a GeoNodeClient
> interface, that supposedly should be implemented so that
> it talks to GeoNode, but for the moment it is just mocked
> so that the integration tests for the classes sitting on top
> of it can work.
>
> Sooo... I need to write the network layer. In order to do that
> it would be quite helpful to have a Geonode with a working
> security API that I can hit. Where do I get that?
>
> Btw, I also never used GeoNode, is there any guide on user management?
>
> Finally, did you see the thread on this ml about the administrator
> user? GeoServer needs an admin level user to work, there is just
> too many parts assuming there is such kind of a user.
> So the json documents exchanged between GeoNode and GeoServer
> should also include a flag telling GeoServer wheter the user
> in question is an administrator or not.
>
> Well, let me know :-)
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
Re: [geonode] GeoServer/GeoNode security integration: where's the
python api?
- From:
- Andrea Aime
- Date:
- 2010-07-14 @ 08:45
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.
Re: [geonode] GeoServer/GeoNode security integration: where's the
python api?
- From:
- Luke Tucker
- Date:
- 2010-07-14 @ 15:10
Glad to hear you were able to get this working :)
On Wed, Jul 14, 2010 at 4:45 AM, Andrea Aime <aaime@opengeo.org> wrote:
>
> 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?)
>
>
I agree there is probably no case for having write permission without read
-- the logical model and user interface for setting these will improve as
this matures. You can see the model in the map security tickets like
http://projects.opengeo.org/CAPRA/ticket/545 -- I assume something similar
will go in for Layers too. At the bottom of it though, there are orthogonal
permissions like unix file permissions, which is what you're seeing. In my
opinion, it's useful to be able to just test for a read permission and not
have to worry about logical implications when checking the ability to read
(or whatever) in the rest of the code.
On Wed, Jul 14, 2010 at 7:20 AM, Andrea Aime <aaime@opengeo.org> wrote:
>
> Btw, the response I get is missing another bit that I need: the user
> name. There are a few parts of GeoServer code that do use the user
> name for error reporting or for logging purposes (e.g. versioning
> WFS), not to mention showing in the admin GUI who are you logged
> in as.
>
> I can fill it myself for the basic auth case, but I cannot do the
> same for cookie based auth.
>
> Can you add a "name" property to the json object you're returning?
Done. The anonymous user's name field comes through as the empty string
with is_anonymous=true.
On Wed, Jul 14, 2010 at 9:26 AM, Andrea Aime <aaime@opengeo.org> wrote:
>
> > 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...
>
> Btw, figured that out in the meantime, it's "sessionid"
>
You're right, but one caveat. The name of this cookie is also a
configurable setting in django. I'm not really sure how often folks need to
change it though.
- Luke
Re: [geonode] GeoServer/GeoNode security integration: where's the
python api?
- From:
- Andrea Aime
- Date:
- 2010-07-14 @ 13:26
Andrea Aime ha scritto:
> 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...
Btw, figured that out in the meantime, it's "sessionid"
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Re: [geonode] GeoServer/GeoNode security integration: where's the
python api?
- From:
- Andrea Aime
- Date:
- 2010-07-14 @ 11:20
Andrea Aime ha scritto:
>>
>> 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...
Btw, the response I get is missing another bit that I need: the user
name. There are a few parts of GeoServer code that do use the user
name for error reporting or for logging purposes (e.g. versioning
WFS), not to mention showing in the admin GUI who are you logged
in as.
I can fill it myself for the basic auth case, but I cannot do the
same for cookie based auth.
Can you add a "name" property to the json object you're returning?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.