Ive searched but not found a solution to our problem,
We have a couple of data security rules for some specific layers, this prevent us from seeding the layers. We are well aware of the problem with security and caching but the gwc service is protected and all our request goes through the wms and with direct integration. Before we could preseed the layers and then recreate the rules but now we have to update the layers on the fly so we really need a solution.
If we try to seed a layer with an rule in data security it logs : Cannot access layer as anonymous
We have tried to put a http username parameter in webcachexml without success. Have also tried to temporary gave anonymous read access to the layer. Nothing works.
Can anyone help with a solution or workaround for this?
On Wed, Jul 8, 2015 at 12:18 PM, Mikael Karlsson <mikael.karlsson@anonymised.com
wrote:
If we try to seed a layer with an rule in data security it logs :
Cannot access layer as anonymous
We have tried to put a http username parameter in webcachexml without
success. Have also tried to temporary gave anonymous read access to the
layer. Nothing works.
Can anyone help with a solution or workaround for this?
Hmm.. I believe the GWC integration should record the Spring Authentication
object used when issuing the
seed request, and feed it into the seeding threads.
Assuming that is the right solution, some coding would be needed to make it
work
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
If we try to seed a layer with an rule in data security it logs : Cannot access layer as anonymous
We have tried to put a http username parameter in webcachexml without success. Have also tried to temporary gave anonymous read access to the layer. Nothing works.
Can anyone help with a solution or workaround for this?
Hmm… I believe the GWC integration should record the Spring Authentication object used when issuing the
seed request, and feed it into the seeding threads.
Assuming that is the right solution, some coding would be needed to make it work
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
On Wed, Jul 8, 2015 at 1:39 PM, Mikael Karlsson <mikael.karlsson@anonymised.com>
wrote:
It sounds logical. Feel like more people should come across this
problem, no one managed to winkle a workaround for it?
I don't think a workaround is possible, the threads doing the seeding are
completely isolated from the request cycles, you either
pass some information explicitly, or it cannot get there.
The change per se should not be too hard, but as usual, a very small
portion of the community is willing/able
to contribute a change, or to sponsor one via commercial support.
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
On Wed, Jul 8, 2015 at 2:02 PM, Mikael Karlsson <mikael.karlsson@anonymised.com>
wrote:
Typical!
Maybe have to look for an alternate way to handle the authentication on
the layers then, maybe a front proxy.
Writing a auth proxy is likely more work, in the long run, than passing
around the auth in GWC, but yes, it's a way.
The GeoShield project a few years ago was acting as a proxy, then they
switched to using the internal
security engine the same way GeoFence does, and they observed a significant
speedup, the proxy overhead
was higher than the time it took to run the WMS requests... since you are
talking about cached tiles instead,
beware of how much slowdown this approach might add.
Ah right, so as an option you could write, and plugin, your own
implementation of ResourceAccessManager (it's the interface
called when checking who can do what):
But now I just read about geofence, is it possible to maybe make this work
with rules in the plugin? And delete the data security rules.
GeoFence just drives the same GeoServer security subsystem as the internal
security, it's just using it fully instead of 30% of its abilities.
So, changing to it won't achieve anything
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
On Wed, Jul 8, 2015 at 1:39 PM, Mikael Karlsson <
mikael.karlsson@
>
wrote:
It sounds logical. Feel like more people should come across this
problem, no one managed to winkle a workaround for it?
I don't think a workaround is possible, the threads doing the seeding are
completely isolated from the request cycles, you either
pass some information explicitly, or it cannot get there.
The change per se should not be too hard, but as usual, a very small
portion of the community is willing/able
to contribute a change, or to sponsor one via commercial support.
Cheers
Andrea
3 years later, and I believe that we have a simple work-around for this
problem that still exists in GeoServer/GeoWebCache.
As a brief recap, if a GS layer is secured under menu item Security > Data,
then when a seeding task is initiated in GWC, the following error is logged
in GS:
But there's an even easier, non-code solution, and that is to insert the
following bean into geoserver/WEB-INF/dispatcher-servlet.xml, which
currently does not have any beans:
We have tested this in production, and if you initiate the seeding task
while logged in as (or POST with the credentials of) a user with access to
the layer, this Authentication object will be copied into the seeding
threads, and it works 100% correctly.
I really hope this helps someone else. My company, AfriGIS, has spent many
hours looking for a solution.
On Wed, Jul 8, 2015 at 1:39 PM, Mikael Karlsson <
mikael.karlsson@
>
wrote:
It sounds logical. Feel like more people should come across this
problem, no one managed to winkle a workaround for it?
I don't think a workaround is possible, the threads doing the seeding are
completely isolated from the request cycles, you either
pass some information explicitly, or it cannot get there.
The change per se should not be too hard, but as usual, a very small
portion of the community is willing/able
to contribute a change, or to sponsor one via commercial support.
Cheers
Andrea
3 years later, and I believe that we have a simple work-around for this
problem that still exists in GeoServer/GeoWebCache.
As a brief recap, if a GS layer is secured under menu item Security > Data,
then when a seeding task is initiated in GWC, the following error is logged
in GS:
But there's an even easier, non-code solution, and that is to insert the
following bean into geoserver/WEB-INF/dispatcher-servlet.xml, which
currently does not have any beans:
We have tested this in production, and if you initiate the seeding task
while logged in as (or POST with the credentials of) a user with access to
the layer, this Authentication object will be copied into the seeding
threads, and it works 100% correctly.
I really hope this helps someone else. My company, AfriGIS, has spent many
hours looking for a solution.
It’s basically the same rules followed by core developers (e.g., if we had to pick up your patch, we’d still
have to create a pull request and write a test for it before merging the change)
It sounds logical. Feel like more people should come across this
problem, no one managed to winkle a workaround for it?
I don’t think a workaround is possible, the threads doing the seeding are
completely isolated from the request cycles, you either
pass some information explicitly, or it cannot get there.
The change per se should not be too hard, but as usual, a very small
portion of the community is willing/able
to contribute a change, or to sponsor one via commercial support.
Cheers
Andrea
3 years later, and I believe that we have a simple work-around for this
problem that still exists in GeoServer/GeoWebCache.
As a brief recap, if a GS layer is secured under menu item Security > Data,
then when a seeding task is initiated in GWC, the following error is logged
in GS:
But there’s an even easier, non-code solution, and that is to insert the
following bean into geoserver/WEB-INF/dispatcher-servlet.xml, which
currently does not have any beans:
We have tested this in production, and if you initiate the seeding task
while logged in as (or POST with the credentials of) a user with access to
the layer, this Authentication object will be copied into the seeding
threads, and it works 100% correctly.
I really hope this helps someone else. My company, AfriGIS, has spent many
hours looking for a solution.
Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.ithttp://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.