[GeoNetwork-devel] Proposal: dynamic geoserver nodes for geopublication

[Landry_Breuil]

Hi,

i've added a new proposal to discuss on the wiki, to allow for more fine-grained publication to geoserver from geonetwork :

https://github.com/geonetwork/core-geonetwork/wiki/Dynamic-Geoserver-nodes-for-geopublication

It is all open to discussion/refinement - i want to make sure that once implemented, it'll be integrated upstream, since this is a rather large change (for me) i dont want to maintain it outside of GN.

Here, we're going to need that feature soonish, and since i'm updating from 2.8 to 2.10 i'm going to implement it at the same time. That has no UI consequences, so should not really interfere with all the UI refactoring that takes place in develop branch - but maybe it might interfere with the spring MVC work.

I know manually fiddling with geoserver's ACL file might not be 'clean' but there's no way to access ACLs via REST (discussed a bit with geoserver developers in https://jira.codehaus.org/browse/GEOS-6308), and geofence within geoserver looks a bit too complicated to me right now.

Please comment on it, if you'd have an interest in seeing this integrated, whether it looks sane, needs improvement or not really appropriate .. all feedback welcomed!

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Jesse_Eichar2]

Hi,

I have a couple minor points to make:

1. You mention that your solution is to use LDAP for obtaining the role names etc… Perhaps you already intend to implement it in this way but my thought is that users already have Roles obtained during the security check etc… You can configure the security subsystem to obtain the Roles from LDAP already so you can keep your code abstract (no LDAP dependency) by simply using User.getAuthorities() to list all the available roles.
2. You mention updating the geoserver nodes configuration on the fly. If you add this ability do you think you could also add a geoserver_node configuration API so that a configuration editor could update the geoserver node configuration as well? (Or even better develop suggested configuration editor ).
3. Remember that the geoserver nodes configuration does not need to stay in a xml file but can be moved to the database where it can be migrated across GeoNetwork versions easier.

Looks like an excellent proposal. I look forward to reviewing the Pull Request.

Jesse

···

On Wed, Feb 5, 2014 at 6:26 PM, Landry Breuil <breuil@anonymised.com> wrote:

Hi,

i’ve added a new proposal to discuss on the wiki, to allow for more
fine-grained publication to geoserver from geonetwork :

https://github.com/geonetwork/core-geonetwork/wiki/Dynamic-Geoserver-nodes-for-geopublication

It is all open to discussion/refinement - i want to make sure that once
implemented, it’ll be integrated upstream, since this is a rather large
change (for me) i dont want to maintain it outside of GN.

Here, we’re going to need that feature soonish, and since i’m updating
from 2.8 to 2.10 i’m going to implement it at the same time. That has no
UI consequences, so should not really interfere with all the UI
refactoring that takes place in develop branch - but maybe it might
interfere with the spring MVC work.

I know manually fiddling with geoserver’s ACL file might not be ‘clean’
but there’s no way to access ACLs via REST (discussed a bit with
geoserver developers in https://jira.codehaus.org/browse/GEOS-6308), and
geofence within geoserver looks a bit too complicated to me right now.

Please comment on it, if you’d have an interest in seeing this
integrated, whether it looks sane, needs improvement or not really
appropriate … all feedback welcomed!

–
Landry Breuil
Mouton a 5 pattes du CRAIG

---

Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk

---

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

[Landry_Breuil]

On 02/06/14 07:51, Jesse Eichar wrote:

Hi,

I have a couple minor points to make:

1. You mention that your solution is to use LDAP for obtaining the role
    names etc... Perhaps you already intend to implement it in this way
    but my thought is that users already have Roles obtained during the
    security check etc... You can configure the security subsystem to
    obtain the Roles from LDAP already so you can keep your code
    abstract (no LDAP dependency) by simply using User.getAuthorities()
    to list all the available roles.

I dont really see what you mean by 'roles' - to me, binding to ldap allows to fetch geonetwork groups and user profiles, and in that case i need a third notion of usergroups, that doesnt necessarly map to existing groups. Groups are for who can access/read data, in my case it's more a 'who can write' thing. Or i misunderstood something..

Do you have an example of those so-called roles usage via getAuthorities, and how it differs from groups/profiles ?

2. You mention updating the geoserver nodes configuration on the fly.
      If you add this ability do you think you could also add a
    geoserver_node configuration API so that a configuration editor
    could update the geoserver node configuration as well? (Or even
    better develop suggested configuration editor ).

Having a fullblown configuration editor within geonetwork to manage the list of geoserver nodes is definitely a bigger task i wont tackle in that proposal. Since the geonetwork UI is going to change a lot, i dont want to make lots of UI changes in that proposal (in fact, only having the list of distant geoserver nodes changing on the fly will already be hard enough from extjs)

3. Remember that the geoserver nodes configuration does not need to
    stay in a xml file but can be moved to the database where it can be
    migrated across GeoNetwork versions easier.

If there's no need to keep them in an xml file, then yeah maybe a database table (+ a migration task, i suppose ?) would be a better fit to store this, especially if it becomes dynamic and changes over time.

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Jesse_Eichar2]

On Thu, Feb 6, 2014 at 10:36 AM, Landry Breuil <breuil@anonymised.com> wrote:

On 02/06/14 07:51, Jesse Eichar wrote:
> Hi,
>
> I have a couple minor points to make:
>
> 1. You mention that your solution is to use LDAP for obtaining the role
> names etc... Perhaps you already intend to implement it in this way
> but my thought is that users already have Roles obtained during the
> security check etc... You can configure the security subsystem to
> obtain the Roles from LDAP already so you can keep your code
> abstract (no LDAP dependency) by simply using User.getAuthorities()
> to list all the available roles.

I dont really see what you mean by 'roles' - to me, binding to ldap
allows to fetch geonetwork groups and user profiles, and in that case i
need a third notion of usergroups, that doesnt necessarly map to
existing groups. Groups are for who can access/read data, in my case
it's more a 'who can write' thing. Or i misunderstood something..

Do you have an example of those so-called roles usage via
getAuthorities, and how it differs from groups/profiles ?

The current LDAP support maps attributes from the LDAP to a User object.
This includes several dimensions Authorities, Geonetwork Profiles
(Reviewer, Editor, ...) and Geonetwork Groups. Also (of course) we have a
database implementation that has all of these concepts.

My point was simply to try to not be LDAP dependant but rather use these
existing concepts in order to be more general and making your extension
functional for a non-LDAP application as well.

I am aware that for GeoServer you also need a shared repository for ACL and
that is fine if you use LDAP for that management. I just want the option
to be able to store that information in another source (like a database) if
I want.

It could be that is what you where always going to do but it wasn't clear
from the proposal.

> 2. You mention updating the geoserver nodes configuration on the fly.
> If you add this ability do you think you could also add a
> geoserver_node configuration API so that a configuration editor
> could update the geoserver node configuration as well? (Or even
> better develop suggested configuration editor ).

Having a fullblown configuration editor within geonetwork to manage the
list of geoserver nodes is definitely a bigger task i wont tackle in
that proposal. Since the geonetwork UI is going to change a lot, i dont
want to make lots of UI changes in that proposal (in fact, only having
the list of distant geoserver nodes changing on the fly will already be
hard enough from extjs)

I thought that you might not have the time but I can always try :-). If
you can have an API that is useable for later constructing said API that
would be nice. I think you might need it to do your work anyways. Even if
the API is not full-featured at first that is fine. (And just a suggestion
I won't block your proposal on this point).
  <http://sourceforge.net/projects/geonetwork&gt;

Jesse

[Landry_Breuil]

On 02/06/14 11:05, Jesse Eichar wrote:

On Thu, Feb 6, 2014 at 10:36 AM, Landry Breuil <breuil@anonymised.com
<mailto:breuil@anonymised.com>> wrote:

    On 02/06/14 07:51, Jesse Eichar wrote:
     > Hi,
     >
     > I have a couple minor points to make:
     >
     > 1. You mention that your solution is to use LDAP for obtaining
    the role
     > names etc... Perhaps you already intend to implement it in
    this way
     > but my thought is that users already have Roles obtained
    during the
     > security check etc... You can configure the security
    subsystem to
     > obtain the Roles from LDAP already so you can keep your code
     > abstract (no LDAP dependency) by simply using
    User.getAuthorities()
     > to list all the available roles.

    I dont really see what you mean by 'roles' - to me, binding to ldap
    allows to fetch geonetwork groups and user profiles, and in that case i
    need a third notion of usergroups, that doesnt necessarly map to
    existing groups. Groups are for who can access/read data, in my case
    it's more a 'who can write' thing. Or i misunderstood something..

    Do you have an example of those so-called roles usage via
    getAuthorities, and how it differs from groups/profiles ?

The current LDAP support maps attributes from the LDAP to a User object.
  This includes several dimensions Authorities, Geonetwork Profiles
(Reviewer, Editor, ...) and Geonetwork Groups. Also (of course) we
have a database implementation that has all of these concepts.

What do you mean by authorities there ? The roles passed by spring security ? What are they used for in geonetwork so far ?

My point was simply to try to not be LDAP dependant but rather use these
existing concepts in order to be more general and making your extension
functional for a non-LDAP application as well.

You mean, having a new database table storing uid -> geoserver 'groups' mappings, being populated either via ldap (as it is done now for gn groups/users) or manually ? I also considered this, but i wasnt sure adding new database tables for that was that much a good idea, since you always need to make sure its in sync with your external source (in my case, LDAP)..

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Jesse_Eichar2]

> On 02/06/14 07:51, Jesse Eichar wrote:
> > Hi,
> >
> > I have a couple minor points to make:
> >
> > 1. You mention that your solution is to use LDAP for obtaining
> the role
> > names etc... Perhaps you already intend to implement it in
> this way
> > but my thought is that users already have Roles obtained
> during the
> > security check etc... You can configure the security
> subsystem to
> > obtain the Roles from LDAP already so you can keep your code
> > abstract (no LDAP dependency) by simply using
> User.getAuthorities()
> > to list all the available roles.
>
> I dont really see what you mean by 'roles' - to me, binding to ldap
> allows to fetch geonetwork groups and user profiles, and in that
case i
> need a third notion of usergroups, that doesnt necessarly map to
> existing groups. Groups are for who can access/read data, in my case
> it's more a 'who can write' thing. Or i misunderstood something..
>
> Do you have an example of those so-called roles usage via
> getAuthorities, and how it differs from groups/profiles ?
>
>
> The current LDAP support maps attributes from the LDAP to a User object.
> This includes several dimensions Authorities, Geonetwork Profiles
> (Reviewer, Editor, ...) and Geonetwork Groups. Also (of course) we
> have a database implementation that has all of these concepts.

What do you mean by authorities there ? The roles passed by spring
security ? What are they used for in geonetwork so far ?

I was getting a little confused between Geonetwork and Spring-Security and
other Geonetwork projects I did in the past. In Spring-Security the
Authorities can be any thing in the LDAP I am looking at
User#getAuthorities now and I see that at the moment it is only Profiles.
So I see where the confusion is.

Perhaps you can:
1. Modify user to have a new field
2. Modify the LDap user loading to populate the new field.

That would allow us to keep the separation between LDAP and the
authorization needed for Geoserver administration.

> My point was simply to try to not be LDAP dependant but rather use these
> existing concepts in order to be more general and making your extension
> functional for a non-LDAP application as well.

You mean, having a new database table storing uid -> geoserver 'groups'
mappings, being populated either via ldap (as it is done now for gn
groups/users) or manually ? I also considered this, but i wasnt sure
adding new database tables for that was that much a good idea, since you
always need to make sure its in sync with your external source (in my
case, LDAP)..

I don't think you need to create any new tables. User creation at the
moment populates User objects with profiles and groups. I think you could
populate the in-memory user object only with the information you need (as
you see above).

Just a thought. No need to stress yourself too much about this.

Jesse

[Landry_Breuil]

On 02/06/14 13:49, Jesse Eichar wrote:

     > On 02/06/14 07:51, Jesse Eichar wrote:
     > > Hi,
     > >
     > > I have a couple minor points to make:
     > >
     > > 1. You mention that your solution is to use LDAP for
    obtaining
     > the role
     > > names etc... Perhaps you already intend to implement
    it in
     > this way
     > > but my thought is that users already have Roles obtained
     > during the
     > > security check etc... You can configure the security
     > subsystem to
     > > obtain the Roles from LDAP already so you can keep
    your code
     > > abstract (no LDAP dependency) by simply using
     > User.getAuthorities()
     > > to list all the available roles.
     >
     > I dont really see what you mean by 'roles' - to me, binding
    to ldap
     > allows to fetch geonetwork groups and user profiles, and in
    that case i
     > need a third notion of usergroups, that doesnt necessarly map to
     > existing groups. Groups are for who can access/read data, in
    my case
     > it's more a 'who can write' thing. Or i misunderstood something..
     >
     > Do you have an example of those so-called roles usage via
     > getAuthorities, and how it differs from groups/profiles ?
     >
     > The current LDAP support maps attributes from the LDAP to a User
    object.
     > This includes several dimensions Authorities, Geonetwork Profiles
     > (Reviewer, Editor, ...) and Geonetwork Groups. Also (of course) we
     > have a database implementation that has all of these concepts.

    What do you mean by authorities there ? The roles passed by spring
    security ? What are they used for in geonetwork so far ?

I was getting a little confused between Geonetwork and Spring-Security
and other Geonetwork projects I did in the past. In Spring-Security the
Authorities can be any thing in the LDAP I am looking at
User#getAuthorities now and I see that at the moment it is only
Profiles. So I see where the confusion is.

Perhaps you can:
1. Modify user to have a new field
2. Modify the LDap user loading to populate the new field.

Yes i also thought about this, but it's a bit awkward if you want to have multiple values for the given new field. Say, user a could be in groups g1 and g2, being able to write to workspaces g1* and g2* - that's doable if you have a mapping on groups (and then, an additional table, like the existing user groups) but not really possible with a single field (or you cheat and concatenate values in a single field having 'g1,g2' value - which is a bit gross IMO)

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Jesse_Eichar2]

Yes i also thought about this, but it's a bit awkward if you want to
have multiple values for the given new field. Say, user a could be in
groups g1 and g2, being able to write to workspaces g1* and g2* - that's
doable if you have a mapping on groups (and then, an additional table,
like the existing user groups) but not really possible with a single
field (or you cheat and concatenate values in a single field having
'g1,g2' value - which is a bit gross IMO)

I was talking about a Java object field, which could be a collection. It
would be read direct from LDAP, it doesn't ahve to be in the database.

Jesse

[Landry_Breuil]

On 02/06/14 14:11, Jesse Eichar wrote:

    Yes i also thought about this, but it's a bit awkward if you want to
    have multiple values for the given new field. Say, user a could be in
    groups g1 and g2, being able to write to workspaces g1* and g2* - that's
    doable if you have a mapping on groups (and then, an additional table,
    like the existing user groups) but not really possible with a single
    field (or you cheat and concatenate values in a single field having
    'g1,g2' value - which is a bit gross IMO)

I was talking about a Java object field, which could be a collection.
  It would be read direct from LDAP, it doesn't ahve to be in the database.

Right, but in that case, how would you populate it without being tied to a ldap ?

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Jesse_Eichar2]

On Thu, Feb 6, 2014 at 2:17 PM, Landry Breuil <breuil@anonymised.com> wrote:

On 02/06/14 14:11, Jesse Eichar wrote:

    Yes i also thought about this, but it's a bit awkward if you want to
    have multiple values for the given new field. Say, user a could be in
    groups g1 and g2, being able to write to workspaces g1* and g2* -
that's
    doable if you have a mapping on groups (and then, an additional table,
    like the existing user groups) but not really possible with a single
    field (or you cheat and concatenate values in a single field having
    'g1,g2' value - which is a bit gross IMO)

I was talking about a Java object field, which could be a collection.
  It would be read direct from LDAP, it doesn't ahve to be in the
database.

Right, but in that case, how would you populate it without being tied to a
ldap ?

In Spring-security the code that loads users is a strategy and is
configured in the config-security***.xml files.

You would change the existing LDAP code that loads the users to populate
your new field/collection in User.

By default the field in the User object will be empty and you can add some
default behaviour if it is empty (or you can provide some defaults for the
field).

Then in the future if there is a system where the Geoserver and Geonetwork
authorithies are loaded from a Non-LDAP source (eg database, github
account, google account, whatever). The future developer will slot in his
implementation code for the User loading code.

That means the LDAP dependency stays at the User loading site and does not
spread itself further into the code base creating a tighter link to LDAP.

Does that make sense?

Currently the LDAP strategy is set by including config-security-ldap.xml in
the config-security.xml file.

AbstractLDAPUserDetailsContextMapper has much of the common code for doing
the LDAP access but there are a couple utility classes and subclasses.

Jesse

[Landry_Breuil]

On 02/06/14 14:45, Jesse Eichar wrote:

On Thu, Feb 6, 2014 at 2:17 PM, Landry Breuil <breuil@anonymised.com
<mailto:breuil@anonymised.com>> wrote:

    On 02/06/14 14:11, Jesse Eichar wrote:

             Yes i also thought about this, but it's a bit awkward if
        you want to
             have multiple values for the given new field. Say, user a
        could be in
             groups g1 and g2, being able to write to workspaces g1* and
        g2* - that's
             doable if you have a mapping on groups (and then, an
        additional table,
             like the existing user groups) but not really possible with
        a single
             field (or you cheat and concatenate values in a single
        field having
             'g1,g2' value - which is a bit gross IMO)

        I was talking about a Java object field, which could be a
        collection.
           It would be read direct from LDAP, it doesn't ahve to be in
        the database.

    Right, but in that case, how would you populate it without being
    tied to a ldap ?

In Spring-security the code that loads users is a strategy and is
configured in the config-security***.xml files.

You would change the existing LDAP code that loads the users to populate
your new field/collection in User.

By default the field in the User object will be empty and you can add
some default behaviour if it is empty (or you can provide some defaults
for the field).

Then in the future if there is a system where the Geoserver and
Geonetwork authorithies are loaded from a Non-LDAP source (eg database,
github account, google account, whatever). The future developer will
slot in his implementation code for the User loading code.

That means the LDAP dependency stays at the User loading site and does
not spread itself further into the code base creating a tighter link to
LDAP.

Does that make sense?

Currently the LDAP strategy is set by including config-security-ldap.xml
in the config-security.xml file.

AbstractLDAPUserDetailsContextMapper has much of the common code for
doing the LDAP access but there are a couple utility classes and subclasses.

I see more or less how all that stuff works, so to summarize for you it'd be:
- add a new mapping in config-security-overrides.properties to map a new ldap attr to a new user field/collection, defaulting to empty
- modify one (or create a new?) of the ldapUserContextMapper (here i use the one with profile search) in config-security-ldap.xml to load that field into one of the attributes of the ContextMapper class
- store that information in a new field in the user database table (or cheat and reuse an existing one, in my case that would map to organisation)
- use it in the geopublisher code to know in which geoserver workspace the user can write

But then, how do you handle multiple values in the database table, how do you store them in a single ldap attr, and how does a java Collection helps here ? there has to be some serialization at some point..

Or, to handle multiple values, it has to be a new table mapping uids to geoserver workspaces, like it's done for geonetwork groups.

Since i'm going to probably move the geoserver node configuration to a new database table, that would be 'simple' to map uids to geoserver node ids..

--
Landry Breuil
Mouton a 5 pattes du CRAIG

[Francois_Prunayre]

Nice proposal Landry

create workspaces on the fly via REST for a given user being part of a given group

Question about the REST API, Could could we add an option to choose the workspace to publish in and If we use the user account to access the REST API instead of the geoserver account then the list could be only the workspaces accessible to the current user ?

FYI, the geopublisher looks like that in the new editor: https://docs.google.com/file/d/0BwyvNKYgG4ZWQ21RZl9FS2dkb3c/edit

Cheers.

Francois

2014-02-06 Landry Breuil <breuil@anonymised.com>:

On 02/06/14 07:51, Jesse Eichar wrote:

Hi,

I have a couple minor points to make:

1. You mention that your solution is to use LDAP for obtaining the role
   names etc… Perhaps you already intend to implement it in this way
   but my thought is that users already have Roles obtained during the
   security check etc… You can configure the security subsystem to
   obtain the Roles from LDAP already so you can keep your code
   abstract (no LDAP dependency) by simply using User.getAuthorities()
   to list all the available roles.

I dont really see what you mean by ‘roles’ - to me, binding to ldap
allows to fetch geonetwork groups and user profiles, and in that case i
need a third notion of usergroups, that doesnt necessarly map to
existing groups. Groups are for who can access/read data, in my case
it’s more a ‘who can write’ thing. Or i misunderstood something…

Do you have an example of those so-called roles usage via
getAuthorities, and how it differs from groups/profiles ?

2. You mention updating the geoserver nodes configuration on the fly.
   If you add this ability do you think you could also add a
   geoserver_node configuration API so that a configuration editor
   could update the geoserver node configuration as well? (Or even
   better develop suggested configuration editor ).

Having a fullblown configuration editor within geonetwork to manage the
list of geoserver nodes is definitely a bigger task i wont tackle in
that proposal. Since the geonetwork UI is going to change a lot, i dont
want to make lots of UI changes in that proposal (in fact, only having
the list of distant geoserver nodes changing on the fly will already be
hard enough from extjs)

3. Remember that the geoserver nodes configuration does not need to
   stay in a xml file but can be moved to the database where it can be
   migrated across GeoNetwork versions easier.

If there’s no need to keep them in an xml file, then yeah maybe a
database table (+ a migration task, i suppose ?) would be a better fit
to store this, especially if it becomes dynamic and changes over time.

–
Landry Breuil
Mouton a 5 pattes du CRAIG

---

Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk

---

GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

[Landry_Breuil]

Le 02/13/14 17:29, Francois Prunayre a écrit :

Nice proposal Landry

create workspaces on the fly via REST for a given user being part of a

given group

Question about the REST API, Could could we add an option to choose the
workspace to publish in and If we use the user account to access the
REST API instead of the geoserver account then the list could be only
the workspaces accessible to the current user ?

I thought about this too, as of now it's a bit awkward to publish
everything via a priviledged admin account on geoserver, but that'd be
much more work imo.. since geonetwork would have to assume that it has
the same credentials/user database as geoserver (which is the case in
our SDIs via cas/ldap, but not necessarely everywhere..)

But filtering the list of available workspaces and showing only a subset
to the user (based on its current role) was definitely my goal.

Planning-wise, i'd really like to play with the new UI, but the original
plan was first to update to 2.10 and add the dynamic geoserver feature
on top of it, and THEN move to 3.0. So i originally planned to make the
feature on 2.10, and forward-port it to develop, but maybe it'd be wiser
to do it the other way round. Or ditch 2.10 completely.. maybe too much
work at once.

FYI, the geopublisher looks like that in the new
editor: https://docs.google.com/file/d/0BwyvNKYgG4ZWQ21RZl9FS2dkb3c/edit

Yes, i've built & run the refactor_editorui branch via mvn jetty:start
and saw this - looks definitely nice. I guess the xml to json transition
is done automatically by the glue underneath, and we dont need to care
about that ?

On an unrelated note, it seems geonetwork.war fails to start in tomcat6,
be it from develop or refactor_editorui branch - anyone saw that too ?

Landry

[Francois_Prunayre]

Le 13 févr. 2014 17:46, “Landry Breuil” <breuil@anonymised.com> a écrit :

Le 02/13/14 17:29, Francois Prunayre a écrit :

Nice proposal Landry

create workspaces on the fly via REST for a given user being part of a
given group

Question about the REST API, Could could we add an option to choose the
workspace to publish in and If we use the user account to access the
REST API instead of the geoserver account then the list could be only
the workspaces accessible to the current user ?

I thought about this too, as of now it’s a bit awkward to publish
everything via a priviledged admin account on geoserver, but that’d be
much more work imo… since geonetwork would have to assume that it has
the same credentials/user database as geoserver (which is the case in
our SDIs via cas/ldap, but not necessarely everywhere…)

We could have 4 types of config :

1. configure one account to use (like current config)
2. get user privileges from a LDAP as you suggested
3. use current account to query the REST API (when using CAS for example)
4. prompt for username/password to query the REST API

Option 4 could be easier to setup ?

But filtering the list of available workspaces and showing only a subset
to the user (based on its current role) was definitely my goal.

Planning-wise, i’d really like to play with the new UI, but the original
plan was first to update to 2.10 and add the dynamic geoserver feature
on top of it, and THEN move to 3.0. So i originally planned to make the
feature on 2.10, and forward-port it to develop, but maybe it’d be wiser
to do it the other way round. Or ditch 2.10 completely… maybe too much
work at once.

We’re currently testing a lot refactor_editorui branch and it will be used in the GéoSource version in march so we expect to have a stable version soon.

FYI, the geopublisher looks like that in the new
editor: https://docs.google.com/file/d/0BwyvNKYgG4ZWQ21RZl9FS2dkb3c/edit

Yes, i’ve built & run the refactor_editorui branch via mvn jetty:start
and saw this - looks definitely nice. I guess the xml to json transition
is done automatically by the glue underneath, and we dont need to care
about that ?

In develop branch, you can add @json flag after servicename in URL @json?params to get a JSON response.

On an unrelated note, it seems geonetwork.war fails to start in tomcat6,
be it from develop or refactor_editorui branch - anyone saw that too ?

Tested on multiple tomcat 7 here with no issue.

Francois

Landry

---

Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk

---

GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

[Landry_Breuil]

On 02/05/14 18:26, Landry Breuil wrote:

Hi,

i've added a new proposal to discuss on the wiki, to allow for more
fine-grained publication to geoserver from geonetwork :

https://github.com/geonetwork/core-geonetwork/wiki/Dynamic-Geoserver-nodes-for-geopublication

It is all open to discussion/refinement - i want to make sure that once
implemented, it'll be integrated upstream, since this is a rather large
change (for me) i dont want to maintain it outside of GN.

Here, we're going to need that feature soonish, and since i'm updating
from 2.8 to 2.10 i'm going to implement it at the same time. That has no
UI consequences, so should not really interfere with all the UI
refactoring that takes place in develop branch - but maybe it might
interfere with the spring MVC work.

I know manually fiddling with geoserver's ACL file might not be 'clean'
but there's no way to access ACLs via REST (discussed a bit with
geoserver developers in https://jira.codehaus.org/browse/GEOS-6308), and
geofence within geoserver looks a bit too complicated to me right now.

Please comment on it, if you'd have an interest in seeing this
integrated, whether it looks sane, needs improvement or not really
appropriate .. all feedback welcomed!

Fwiw, i've been a bit swamped by other stuff @work, but the wip on this i started is on https://github.com/landryb/core-geonetwork/tree/feature/geopublish-by-org - a bit of refactoring only, but at least i can list workspaces, show them to the user, and he can publish in any of them.

This also depends a bit on https://github.com/landryb/core-geonetwork/tree/bugfix/force-geoserver-auth since without it i cant make geonetwork auth properly with my geoserver, the way the latter is configured.

I definitely plan to work on this in the coming months, but more eyes on my coding style are welcome..

--
Landry Breuil
Mouton a 5 pattes du CRAIG