Re: [Geoserver-devel] Pre-proposal discussion, amending community module graduation rules
Hi Gabriel, I think that adding them to the build and running tests misses the point of being community modules; if I am not mistaken, they might actually not have tests at all. That said, I would be careful with adding more stuff to the build which already takes a long time. Raising the test coverage is a good practice; I am ok with that but we need to decide what to do with existing modules whose coverage might be below 40%. Maybe a topic for a separate discussion? Regards, Simone Giannecchini == Online training classes for GeoNode, GeoServer and MapStore from the experts! Visit https://www.geosolutionsgroup.com/professional-training/ for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions Italy President GeoSolutions USA phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 US: +1 (845) 547-7905 http://www.geosolutionsgroup.com http://twitter.com/geosolutions_it --- This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail. On Wed, Mar 13, 2024 at 5:15 PM Gabriel Roldan < gabriel.rol...@camptocamp.com> wrote: > I like Jody's alternative wording. > > I may be mistaken but there seems to be two kinds of community modules. > Those that are in the communityRelease profile and those that aren't. > Here's an idea: for those that are, it'd be good to have a build job that > runs the tests, and they should be required to pass tests to stay in the > communityRelease profile. > For graduation, 40% test coverage seems rather low a requirement? > *camptocamp* > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Gabriel Roldán* > Geospatial Developer > > > > On Wed, Mar 13, 2024 at 5:41 AM Alessio Fabiani < > alessio.fabi...@geosolutionsgroup.com> wrote: > >> Agree, and +1. The proposal makes sense. Also +1 for the Jody statement >> also. Of course a community module should not contain any kind of ad-hoc or >> hard-coded stuff in order to be merged. >> >> On Tue, Mar 12, 2024 at 6:21 PM Jody Garnett >> wrote: >> >>> Andrea: >>> >>> I am in favour of being less *specific* in these kind of requirements >>> in preference to stating the goal and providing an example. >>> >>> "The module is not site specific and can be configured for use by the >>> general GeoServer community. A community module that already has 3 users >>> would meet this goal; while a community module that has hard coded a domain >>> name would not." >>> >>> (And I will stay on topic) >>> -- >>> Jody Garnett >>> >>> >>> On Mar 12, 2024 at 4:19:42 AM, Andrea Aime < >>> andrea.a...@geosolutionsgroup.com> wrote: >>> Hi all, I'm starting this conversation to see if/how we can amend the procedures for graduating a community module a bit. For reference, the current procedure is here: https://docs.geoserver.org/latest/en/developer/policies/community-modules.html#id2 In particular, I'm thinking about requirement "1", the module has at least 3 users. The reason for the check is a good one, we don't want to clutter the main code base with modules that are specific to one single user site. At the same time, this creates a "chicken and egg" problem, because many sites won't consider using a module until it's supported. So, I'd like to keep the intent of requirement 1, but propose a change in its implementation. 3 usage sites can be one of the options, but can we also consider a PSC opinion on the matter as a valid alternative? And a PSC member can provide feedback on the module generality while the graduation is being voted. I know that Jody wants to also talk about point 3 (module being stable, as a prerequisite, the standards that the module is based on being stable too), but can we please have a separate thread for that? Best regards Andrea == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it --- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza
[Geoserver-devel] Keycloak authentication not working
Hi, I'm looking into how to authenticate against a Keycloak server. I'm using Geoserver 2.24.2 and Keycloak 23.0.6. In Geoserver I have configured a "Keycloak OpenID Authentication" filter with the config from Keycloak server and disabled the checkbox "Enable Redirect to Keycloak Login page". Then I have changed the filter chain for "web", so that it lists keycloak at the top of the list of filters. At the bottom I have "anonymous". This doesn't work. I've turned on full logging for keycloak both in "org.geoserver.security.keycloak" and "org.keycloak". What I see is that it get's the token from the Keycloak server, so that communication is working, but fails to initiate a HTTP forwarding. When I debug the solution I see that an AnonymousAuthenticationToken is set into SecurityContextHolder.getContext().setAuthentication. And that it stays there for all the subsequent calls. That will prevail GeoserverKeycloakAuthenticationFilter to do any more tries to authenticate against the Keycloak server. I have tried without the anonymous filter, but then I can't get into the web site at all. Is AnonymousAuthenticationToken meant to be reused in subsequent calls, like maybe it comes from the Session? Or should it be cleared at the top of the filter chain? Do anyone have an example of the Authentication settings in Geoserver for a solution using Keycloak as an Authentication filter, and that is working? Best regards, Roar Brænden ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Pre-proposal discussion, amending community module graduation rules
I like Jody's alternative wording. I may be mistaken but there seems to be two kinds of community modules. Those that are in the communityRelease profile and those that aren't. Here's an idea: for those that are, it'd be good to have a build job that runs the tests, and they should be required to pass tests to stay in the communityRelease profile. For graduation, 40% test coverage seems rather low a requirement? *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS *Gabriel Roldán* Geospatial Developer On Wed, Mar 13, 2024 at 5:41 AM Alessio Fabiani < alessio.fabi...@geosolutionsgroup.com> wrote: > Agree, and +1. The proposal makes sense. Also +1 for the Jody statement > also. Of course a community module should not contain any kind of ad-hoc or > hard-coded stuff in order to be merged. > > On Tue, Mar 12, 2024 at 6:21 PM Jody Garnett > wrote: > >> Andrea: >> >> I am in favour of being less *specific* in these kind of requirements in >> preference to stating the goal and providing an example. >> >> "The module is not site specific and can be configured for use by the >> general GeoServer community. A community module that already has 3 users >> would meet this goal; while a community module that has hard coded a domain >> name would not." >> >> (And I will stay on topic) >> -- >> Jody Garnett >> >> >> On Mar 12, 2024 at 4:19:42 AM, Andrea Aime < >> andrea.a...@geosolutionsgroup.com> wrote: >> >>> Hi all, >>> I'm starting this conversation to see if/how we can amend the procedures >>> for graduating a community module a bit. >>> >>> For reference, the current procedure is here: >>> >>> https://docs.geoserver.org/latest/en/developer/policies/community-modules.html#id2 >>> >>> In particular, I'm thinking about requirement "1", the module has at >>> least 3 users. >>> The reason for the check is a good one, we don't want to clutter the >>> main code base with modules that are specific to one single user site. At >>> the same time, this creates a "chicken and egg" problem, because many sites >>> won't consider using a module until it's supported. >>> >>> So, I'd like to keep the intent of requirement 1, but propose a change >>> in its implementation. 3 usage sites can be one of the options, but can we >>> also consider a PSC opinion on the matter as a valid alternative? And a PSC >>> member can provide feedback on the module generality while the graduation >>> is being voted. >>> >>> I know that Jody wants to also talk about point 3 (module being stable, >>> as a prerequisite, the standards that the module is based on being stable >>> too), but can we please have a separate thread for that? >>> >>> Best regards >>> Andrea >>> >>> == >>> GeoServer Professional Services from the experts! >>> >>> Visit http://bit.ly/gs-services-us for more information. >>> == >>> >>> Ing. Andrea Aime >>> @geowolf >>> Technical Lead >>> >>> GeoSolutions Group >>> phone: +39 0584 962313 >>> >>> fax: +39 0584 1660272 >>> >>> mob: +39 339 8844549 >>> >>> https://www.geosolutionsgroup.com/ >>> >>> http://twitter.com/geosolutions_it >>> >>> --- >>> >>> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >>> precisa che ogni circostanza inerente alla presente email (il suo >>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >>> >>> This email is intended only for the person or entity to which it is >>> addressed and may contain information that is privileged, confidential or >>> otherwise protected from disclosure. We remind that - as provided by >>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >>> e-mail or the information herein by anyone other than the intended >>> recipient is prohibited. If you have received this email by mistake, please >>> notify us immediately by telephone or e-mail >>> ___ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> ___ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > -- > > Regards, > > Alessio Fabiani > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Alessio Fabiani > > @alfa7691 > Founder/Technical Lead > > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 331 6233686 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > >
Re: [Geoserver-devel] Pre-proposal discussion, amending community module graduation rules
Agree, and +1. The proposal makes sense. Also +1 for the Jody statement also. Of course a community module should not contain any kind of ad-hoc or hard-coded stuff in order to be merged. On Tue, Mar 12, 2024 at 6:21 PM Jody Garnett wrote: > Andrea: > > I am in favour of being less *specific* in these kind of requirements in > preference to stating the goal and providing an example. > > "The module is not site specific and can be configured for use by the > general GeoServer community. A community module that already has 3 users > would meet this goal; while a community module that has hard coded a domain > name would not." > > (And I will stay on topic) > -- > Jody Garnett > > > On Mar 12, 2024 at 4:19:42 AM, Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> Hi all, >> I'm starting this conversation to see if/how we can amend the procedures >> for graduating a community module a bit. >> >> For reference, the current procedure is here: >> >> https://docs.geoserver.org/latest/en/developer/policies/community-modules.html#id2 >> >> In particular, I'm thinking about requirement "1", the module has at >> least 3 users. >> The reason for the check is a good one, we don't want to clutter the main >> code base with modules that are specific to one single user site. At the >> same time, this creates a "chicken and egg" problem, because many sites >> won't consider using a module until it's supported. >> >> So, I'd like to keep the intent of requirement 1, but propose a change in >> its implementation. 3 usage sites can be one of the options, but can we >> also consider a PSC opinion on the matter as a valid alternative? And a PSC >> member can provide feedback on the module generality while the graduation >> is being voted. >> >> I know that Jody wants to also talk about point 3 (module being stable, >> as a prerequisite, the standards that the module is based on being stable >> too), but can we please have a separate thread for that? >> >> Best regards >> Andrea >> >> == >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> == >> >> Ing. Andrea Aime >> @geowolf >> Technical Lead >> >> GeoSolutions Group >> phone: +39 0584 962313 >> >> fax: +39 0584 1660272 >> >> mob: +39 339 8844549 >> >> https://www.geosolutionsgroup.com/ >> >> http://twitter.com/geosolutions_it >> >> --- >> >> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >> precisa che ogni circostanza inerente alla presente email (il suo >> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >> >> This email is intended only for the person or entity to which it is >> addressed and may contain information that is privileged, confidential or >> otherwise protected from disclosure. We remind that - as provided by >> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >> e-mail or the information herein by anyone other than the intended >> recipient is prohibited. If you have received this email by mistake, please >> notify us immediately by telephone or e-mail >> ___ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Regards, Alessio Fabiani == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 331 6233686 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it --- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European
Re: [Geoserver-devel] GSIP 222: Graduating the Raster Attribute Table community module
+0 On Tue, Mar 12, 2024 at 7:46 PM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > Yep if possible. > > Regards, > > Andrea Aime > > > == > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > --- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > > > On Tue, Mar 12, 2024 at 6:13 PM Jody Garnett > wrote: > >> +1 Did you want to include this in the 2.25.0 release also? >> -- >> Jody Garnett >> >> >> On Mar 12, 2024 at 4:23:15 AM, Andrea Aime < >> andrea.a...@geosolutionsgroup.com> wrote: >> >>> Hi all, >>> (hello PSC members!), I'd like to start a discussion about graduating >>> the Raster Attribute Table community module, proposal with details here: >>> >>> https://github.com/geoserver/geoserver/wiki/GSIP-222 >>> >>> Regards, >>> >>> Andrea Aime >>> >>> >>> == >>> GeoServer Professional Services from the experts! >>> >>> Visit http://bit.ly/gs-services-us for more information. >>> == >>> >>> Ing. Andrea Aime >>> @geowolf >>> Technical Lead >>> >>> GeoSolutions Group >>> phone: +39 0584 962313 >>> >>> fax: +39 0584 1660272 >>> >>> mob: +39 339 8844549 >>> >>> https://www.geosolutionsgroup.com/ >>> >>> http://twitter.com/geosolutions_it >>> >>> --- >>> >>> Con riferimento alla normativa sul trattamento dei dati personali (Reg. >>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si >>> precisa che ogni circostanza inerente alla presente email (il suo >>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è >>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il >>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra >>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia. >>> >>> This email is intended only for the person or entity to which it is >>> addressed and may contain information that is privileged, confidential or >>> otherwise protected from disclosure. We remind that - as provided by >>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this >>> e-mail or the information herein by anyone other than the intended >>> recipient is prohibited. If you have received this email by mistake, please >>> notify us immediately by telephone or e-mail >>> ___ >>> Geoserver-devel mailing list >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> ___ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Regards, Alessio Fabiani == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 331 6233686 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it --- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information
