Hi Niels, GeoFence used to provide a REST interface, https://github.com/geoserver/geofence/tree/master/src/services/modules/rest but, after the last improvements and refactoring, it needs some review and fixing. You can find the (old) related doc here: http://goo.gl/NjkvGn (it was partially ported into github wiki pages, but the paragraph formatting is awful there).
REST services are implemented using CXF, so it is also to be seen if CXF (and its transitive deps) will not present any conflict when running inside GeoServer. It's also to be checked/decided if the GeoServer dispatcher could/should be used to route such REST calls. I guess Andrea could give some hints about how to publish the API. Cheers, Emanuele Alle 14:48:11 di Wednesday 8 April 2015, Niels Charlier ha scritto: > Emanuele, > > Thanks! I have added the version updates to my pull request. > > Something else, I need to also make a REST API available on the > integrated geofence. Of course I only need the Rules API. > Do you have any recommendations on how to do that? You reckon I should > make a new one in geoserver and copy-paste or could I depend on a module > and configure to publish it? What are your thoughts? > > Regards > Niels > > On 08-04-15 13:47, Emanuele Tajariol wrote: > > Hi Niels, > > > >> When the geofence 3.0 branch is there I will update > > > > On master branch the version has been updated to 3.0-SNAPSHOT: > > https://github.com/geoserver/geofence/blob/master/src/pom.xml#L15 > > > > The refactor branch has already been merged into master. > > > > Cheers, > > Emanuele > > > > Alle 12:55:36 di Wednesday 8 April 2015, Niels Charlier ha scritto: > >> Hello Emanuele, > >> > >> That sounds good. When the geofence 3.0 branch is there I will update > >> the versions in the geoserver modules. > >> Thanks! Let me know if you need anything else from me. > >> > >> Regards > >> Niels > >> > >> On 07-04-15 12:40, Emanuele Tajariol wrote: > >>> Hi Niels, > >>> > >>> ok, some changes in the geofence branches and versions: > >>> > >>> - Current master has been branched to "2.2.x", > >>> - The user-role refactoring branch is going to be merged into master, > >>> which will be bumped to version 3.0. This major version change is due > >>> to the changes in the base model that will make the previous version > >>> uncompatible. > >>> > >>> For the GeoFence community module in GeoServer 2.7 we'll have to use > >>> the GeoFence 2.2.x branch, in order to have the DTOs matching, while > >>> GeoServer master (2.8) will use GeoFence master (3.0). > >>> > >>> Cheers, > >>> Emanuele > >>> > >>> Alle 16:33:31 di Monday 6 April 2015, Niels Charlier ha scritto: > >>>> I made a pull request for the changes on geoserver: > >>>> https://github.com/geoserver/geoserver/pull/1005 > >>>> > >>>> I've put it there already mainly to get commenting and reviewing > >>>> going. But I do hope we can sort out how to get these changes in the > >>>> official branches of geofence and geoserver soon! > >>>> > >>>> Let me know what you think. > >>>> > >>>> Regards > >>>> Niels > >>>> > >>>> On 06-04-15 11:55, Niels Charlier wrote: > >>>>> Hi Emanuele, > >>>>> > >>>>> Are the geofence refactoring commits going to be pulled in the master > >>>>> branch in the official repo? > >>>>> Because I almost have a pull ready for gs-geofence-server but it > >>>>> depends on those changes being there. > >>>>> > >>>>> > >>>>> Also, I have found a work-around for my eclipse issue. While you > >>>>> can't manipulate the dependency order of included projects from the > >>>>> GUI, there is an order inside the config file behind it (.classpath > >>>>> file in the project dir). The order of the pom doesn't seem to be > >>>>> respected, but I can manually do it. After running maven > >>>>> eclipse:eclipse, I manually edit the .classpath file and move the > >>>>> model-internal dependency above the gs-geofence dependency. That is > >>>>> the best solution for now, but still a bit annoying. There is > >>>>> another really annoying thing in eclipse, there is an > >>>>> application-context.xml in test and it reads it of course. > >>>>> > >>>>> Regards > >>>>> Niels > >>>>> > >>>>> On 02-04-15 13:01, Emanuele Tajariol wrote: > >>>>>> Hi Niels, > >>>>>> > >>>>>>> * Let gs-geofence also use model-internal, but it is probably not > >>>>>>> desire > >>>>>>> to have all that unnecessary hibernate stuff loaded. > >>>>>> > >>>>>> Exactly: the split model was created only because gs-geofence did > >>>>>> import too > >>>>>> much hibernate stuff inside geoserver. > >>>>>> > >>>>>>> * Make them different classes (or in different packages) but use > >>>>>>> interfaces instead for compatibility? Probably would require lots > >>>>>>> of refactoring inside geofence. > >>>>>>> * Can we somehow force geofence-server to use the classes from > >>>>>>> geofence-model-internal even if both are on the classpath? It seems > >>>>>>> that > >>>>>>> java will always use the _first_ on the classpath, but eclipse > >>>>>>> doesn't recognise an order in project dependencies > >>>>>> > >>>>>> These solutions are quite complex, and would be a workaround for a > >>>>>> workaround > >>>>>> (the split model). > >>>>>> I guess the simpler way would be to only have a single model module, > >>>>>> and to > >>>>>> remove the hibernate annotations using the hbm files instead. > >>>>>> I tried to use the hibernate tools for automatically creating the > >>>>>> hbm files out > >>>>>> of the annotations, but they seemed quite bugged. Do you have any > >>>>>> experience > >>>>>> with them? > >>>>>> > >>>>>> Cheers, > >>>>>> Emanuele > >>>>>> > >>>>>> Alle 12:17:37 di Thursday 2 April 2015, Niels Charlier ha scritto: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have a practical problem regarding the difference between > >>>>>>> geofence-model and geofence-model-internal. > >>>>>>> They both contain the same classes, but geofence-model removes the > >>>>>>> hibernate annotations from the build. > >>>>>>> > >>>>>>> gs-geofence uses geofence-model while gs-geofence-server needs > >>>>>>> gs-geofence-model-internal. I solved this earlier by putting an > >>>>>>> exclusion in the geofence-server profile of the web-app pom. The > >>>>>>> problem > >>>>>>> is however eclipse. When you do mvn eclipse:eclipse inside web-app, > >>>>>>> this > >>>>>>> works fine. However, eclipse doesn't add any of the geoserver > >>>>>>> modules as > >>>>>>> "required projects" in the build path, but rather as regular > >>>>>>> external jar files, so you miss the relationship between the code > >>>>>>> and this brings > >>>>>>> inconveniences while programming and debugging. > >>>>>>> > >>>>>>> To solve that you have to do eclipse:eclipse from the geoserver > >>>>>>> source root. But then eclipse doesn't recognise the exclusion... > >>>>>>> and keeps loading the classes from model. And geofence-server > >>>>>>> doesn't work without > >>>>>>> the hibernate annotations. > >>>>>>> > >>>>>>> So, do you guys have any ideas for solutions? > >>>>>>> * Let gs-geofence also use model-internal, but it is probably not > >>>>>>> desire > >>>>>>> to have all that unnecessary hibernate stuff loaded. > >>>>>>> * Make them different classes (or in different packages) but use > >>>>>>> interfaces instead for compatibility? Probably would require lots > >>>>>>> of refactoring inside geofence. > >>>>>>> * Can we somehow force geofence-server to use the classes from > >>>>>>> geofence-model-internal even if both are on the classpath? It seems > >>>>>>> that > >>>>>>> java will always use the _first_ on the classpath, but eclipse > >>>>>>> doesn't recognise an order in project dependencies > >>>>>>> > >>>>>>> Any suggestions? > >>>>>>> > >>>>>>> Regards > >>>>>>> Niels > >>>>>>> > >>>>>>> On 27-03-15 17:16, Emanuele Tajariol wrote: > >>>>>>>> Hi Niels, > >>>>>>>> > >>>>>>>>> What does this setting do: "Use GeoServer roles to get > >>>>>>>>> authorizations"? > >>>>>>>>> > >>>>>>>> GeofencePage.useRolesToFilter=Use GeoServer roles to get > >>>>>>>> authorizations > >>>>>>>> > >>>>>>>> it's related to this proposal: > >>>>>>>> > >>>>>>>> https://github.com/geosolutions-it/geofence/wiki/Proposal-%233:-Ge > >>>>>>>> oS er ver > >>>>>>>> > >>>>>>>> - Roles-to-GeoFence-groups-mapping#configuration > >>>>>>>> > >>>>>>>> It makes the AccessManager query geofence the authorization not > >>>>>>>> for the > >>>>>>>> accessing user, but by the role the user is assigned in GeoServer > >>>>>>>> See also method setRuleFilterUserOrRole. > >>>>>>>> > >>>>>>>> If the roles in geoserver are exactly the same as in geofence (as > >>>>>>>> the current integration work aims to) it should not matter, since > >>>>>>>> the resulting auths will be the same. > >>>>>>>> I mean: if the useRolesToFilter is set to true, the user-role > >>>>>>>> matching will be done in setRuleFilterUserOrRole. If it's set to > >>>>>>>> false, such matching will be performed inside geofence, using the > >>>>>>>> metod UserResolver::getRoles > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Emanuele > >>>>>>>> > >>>>>>>> Alle 16:50:58 di Friday 27 March 2015, Niels Charlier ha scritto: > >>>>>>>>> Hi Emanuele, > >>>>>>>>> > >>>>>>>>> Excellent. What does this setting do: "Use GeoServer roles to get > >>>>>>>>> authorizations"? > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Niels > >>>>>>>>> > >>>>>>>>> On 27-03-15 14:49, Emanuele Tajariol wrote: > >>>>>>>>>> Hi Niels, > >>>>>>>>>> > >>>>>>>>>>> The user/group integration work is that ready or does it still > >>>>>>>>>>> need work? > >>>>>>>>>> > >>>>>>>>>> It's ready. The rule engine needs info about the user, the role > >>>>>>>>>> and their association. You can provide these info by > >>>>>>>>>> implementing this interface > >>>>>>>>>> > >>>>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src > >>>>>>>>>> /s er vic > >>>>>>>>>> > >>>>>>>>>> es /core/services- > >>>>>>>>>> api/src/main/java/org/geoserver/geofence/spi/UserResolver.java > >>>>>>>>>> > >>>>>>>>>> and aliasing this spring bean with the new implementation > >>>>>>>>>> > >>>>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src > >>>>>>>>>> /s er vic > >>>>>>>>>> > >>>>>>>>>> es /core/services- > >>>>>>>>>> impl/src/main/resources/applicationContext.xml#L24 > >>>>>>>>>> > >>>>>>>>>> The default UserResolver uses the DAO toward the geofence DB > >>>>>>>>>> > >>>>>>>>>> https://github.com/etj/geofence/blob/201503_user_role_refact/src > >>>>>>>>>> /s er vic > >>>>>>>>>> > >>>>>>>>>> es /core/services- > >>>>>>>>>> impl/src/main/java/org/geoserver/geofence/services/DefaultUserRe > >>>>>>>>>> so lv er. > >>>>>>>>>> > >>>>>>>>>> j ava > >>>>>>>>>> > >>>>>>>>>> but I guess you'll have to return the users and roles actually > >>>>>>>>>> used in > >>>>>>>>>> GeoServer. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Emanuele > >>>>>>>>>> > >>>>>>>>>> Alle 21:23:40 di Thursday 26 March 2015, Niels Charlier ha scritto: > >>>>>>>>>>> On 26-03-15 16:49, Andrea Aime wrote: > >>>>>>>>>>>> Speaking of hibernate, wondering what might happens if > >>>>>>>>>>>> geofence and > >>>>>>>>>>>> the monitoring hibernate extension are both loaded in > >>>>>>>>>>>> GeoServer. > >>>>>>>>>>> > >>>>>>>>>>> Yeah I haven't tested with the hibernate extension yet. That > >>>>>>>>>>> could indeed cause more trouble > >>>>>>>>>>> > >>>>>>>>>>>> What if the GEOSERVER_DATA_DIR system variable is not defined? > >>>>>>>>>>>> It's > >>>>>>>>>>>> not mandatory. > >>>>>>>>>>>> I guess you could create a subclass of > >>>>>>>>>>>> PropertyOverrideConfigurer depending on > >>>>>>>>>>>> GeoServerResourceLoader and > >>>>>>>>>>>> get the base directory there. > >>>>>>>>>>> > >>>>>>>>>>> think > >>>>>>>>>>> You are right. Something similar has been done in the geofence > >>>>>>>>>>> module > >>>>>>>>>>> for the PropertyPlaceholderConfigurer, will use the same > >>>>>>>>>>> principle. Consider the current version kind of a proof of > >>>>>>>>>>> concept, will still need to fine-tune it. > >>>>>>>>>>> > >>>>>>>>>>>> The other thing that bother me a bit, but it's GeoFence own > >>>>>>>>>>>> fault, it's this business of setting up the data source > >>>>>>>>>>>> inside the Spring context instead of creating it > >>>>>>>>>>>> programmatically, allowing the data source to be read from > >>>>>>>>>>>> some config file, and allow its re-configuration at runtime. > >>>>>>>>>>>> In the long run it would be best if the integrated GeoFence > >>>>>>>>>>>> could start off H2, but allowed configuration > >>>>>>>>>>>> to store the rules somewhere else at runtime, without need for > >>>>>>>>>>>> restarts. > >>>>>>>>>>> > >>>>>>>>>>> Yeah some of the client settings also require a restart for the > >>>>>>>>>>> same > >>>>>>>>>>> reason. The server URL anyway, but that doesn't apply with the > >>>>>>>>>>> internal server. > >>>>>>>>>>> > >>>>>>>>>>> The user/group integration work is that ready or does it still > >>>>>>>>>>> need work? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> Niels -- == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Emanuele Tajariol Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 380 2116282 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
