Ciao Jody,
- Given the results, is it a bug?
Am I correct in thinking that the given endpoint cannot be used for editing; or is it possible to update the entire file in one go and have it preserve order? If the existing endpoint cannot be used with POST or PUT then I would consider this a bug to be fixed.
given the documentation (and the code implementation):
For reference from the openapi documentation page:
https://docs.geoserver.org/latest/en/api/#1.0.0/security.yaml
Geoserver is supporting the GET and the POST but not respecting the order (which is not the insertion even when xml is used).
The PUT implements a PATCH pattern where you can modify only existing rows.
This thread is mainly to add the full Rest PUT functionality where an user with granted PUT permission to /security/acl/rest endpoint can have the full control of the rest resource replacing it in one shot and respecting the order, no matter if the body is xml or json.
The branch is implementing this under /security/acl/rest/update
We can easily change the endpoint as it could clash with an ant path rule to be delete,post,put,get (pls ref to the swagger documentation)
There may also be a second bug:
Andrea is correct about the JSON representation not providing a list to represent order as significant. This may be the point to do a breaking change for the JSON representation.
Yes indeed I’m trying with XML but even with that the insertion order is not respected and natural order is imposed.
Json is not enforcing nor supporting an order but it is also not forbidding to make the correct use of the order when necessary.
For an API like this, where the order is important, I think the order should be kept even when using Json as a container,
- Should I open a ticket or we should reopen the previous one?
I think it would be kinder to reopen the previous ticket; so it is clear that the attempted fix does not work.
Okay, thanks, I’m on hold.
- I see a function which is intentionally limiting only to ADMIN role these kind of calls checkUserIsAdmin();
Are you seeking to setup a new built-in role? In my thinking a user having admin access grants ability to update the system (it should not matter if they are using the REST API or the Admin Console).
I’m thinking of having a managerial role for some users below the superuser role ADMIN and I was thinking why f.e. the GROUP_ADMIN can’t be used to share some system management permission over the platform?
I’ve also tested (with no luck) inheriting my MNG from GROUP_ADMIN role to get more power but I can only see a few things more in the UI, on the REST /security/acl everything looks limited intentionally to the ADMIN role.
So, I was wondering: it’s actually impossible to control the permission level of the users under /security/acl without having to grant or inherit from the ADMIN role, is this something which can be discussed?
Thank you for sharing your thoughts.
Best,
Carlo
···
–
Jody Garnett
Carlo Cancellieri
Skype: ccancellieri
Twitter: @cancellieric
LinkedIn: http://it.linkedin.com/in/ccancellieri/
Regards,
Andrea Aime
==
GeoServer Professional Services from the experts!
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
Carlo Cancellieri
Skype: ccancellieri
Twitter: @cancellieric
LinkedIn: http://it.linkedin.com/in/ccancellieri/
Carlo Cancellieri
Skype: ccancellieri
Twitter: @cancellieric
LinkedIn: http://it.linkedin.com/in/ccancellieri/