[Geoserver-devel] Hazelcast/JDBConfig clustering issues caused by HTTP 302 response and unique wicket resource IDs

GeoServer GeoServer Developer
1

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

2

First up thanks for testing - it is appreciated. I do not thing this was done on purpose, other than we were trying an option for unique wicket URLs (something that comes up in geoserver security audits).

So we have a choice of:

  • changing this back, or
  • using hazelcast to sort out sessions across the cluster; or
  • asking you to set up your load balancer to direct all gui interaction to a single node

Can I ask you if the third option works (even as a workaround). And we should report this to Jira :frowning:

···

On 27 April 2016 at 17:25, Amiram Rahav <arahav@anonymised.com> wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

3

Hi Jody,

Could you go into more detail about what security risk(s) does unique wicket URLs mitigate? Frankly it’s difficult to see how this adds much to security - as soon as you know how this behaves it would be trivial to deal with a 302 and a unique wicket URL from an attack standpoint.

The third option doesn’t really work with AWS ELBs. There isn’t an easy way to route all traffic based on a URL match to a single instance, which means this will require another layer of indirection to configure routing rules.
Session stickiness can be used, but then that also affects REST and OGC calls and isn’t optimal.

Also what you describe is, to a degree, what JMS clustering is where we have one management node and multiple worker nodes. But that requires more infrastructure, and a slave JMS node could act as a master which would more likely than not get us back to this issue.

Option 2 is a given - hazelcast is used for session sharing across cluster nodes, perhaps it should also be used to deal with unique URLs, however the HTTP 302 on every UI interaction is still an issue…

My 2 cents is that option 1 - reverting this change would make the most sense.

I hope other people will chime in…

Thanks,

Ami.

···

–
Jody Garnett

On 27 April 2016 at 17:25, Amiram Rahav arahav@anonymised.com wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

Checking the wiki (and spreadsheet) I could not quickly find the specific configuration change that is intended to randomize generated URLs. The issue comes up each-time-we-get-a-security-audit … although we do not particularly battle harden our administration UI (as we intend people to use the webservices on mass rather than the layer preview screen). I get the impression security audit companies have automated tools that review website pages and point out a list of common mistakes such as this one:

The general story is that each link or action should point to a new URL generated for that sessions to prevent some categories of attack, here is an example of such a report:

Web Application Vulnerable To Crosssite Request Forgery Attacks: Recommend that the web application be modified to check that a request has come from a user-generated process, such as completing a form or clicking a link. In effect, each transaction to be processed should carry a unique ID value. In addition, it is recommended that all functions only transmit their data via POST requests and that when each form is accessed, a random value be set. This random value should then be added to the form (normally via a hidden field) and as a value within the user’s session on the server-side. When the application processes the required POST, it should check that the value hidden in the form and the value stored within the user’s session are the same; if they are not, the request should be rejected.

Some background for wicket:

TLDR: The wicket solution to this is to use KeyInSessionSunJceCryptFactory for forms (rather than a hidden field) resulting in encrypted URLs.

···

On 28 April 2016 at 08:30, Amiram Rahav <arahav@anonymised.com> wrote:

Hi Jody,

Could you go into more detail about what security risk(s) does unique wicket URLs mitigate? Frankly it’s difficult to see how this adds much to security - as soon as you know how this behaves it would be trivial to deal with a 302 and a unique wicket URL from an attack standpoint.

The third option doesn’t really work with AWS ELBs. There isn’t an easy way to route all traffic based on a URL match to a single instance, which means this will require another layer of indirection to configure routing rules.
Session stickiness can be used, but then that also affects REST and OGC calls and isn’t optimal.

Also what you describe is, to a degree, what JMS clustering is where we have one management node and multiple worker nodes. But that requires more infrastructure, and a slave JMS node could act as a master which would more likely than not get us back to this issue.

Option 2 is a given - hazelcast is used for session sharing across cluster nodes, perhaps it should also be used to deal with unique URLs, however the HTTP 302 on every UI interaction is still an issue…

My 2 cents is that option 1 - reverting this change would make the most sense.

I hope other people will chime in…

Thanks,

Ami.

On Wednesday, April 27, 2016, Jody Garnett <jody.garnett@anonymised.com> wrote:

First up thanks for testing - it is appreciated. I do not thing this was done on purpose, other than we were trying an option for unique wicket URLs (something that comes up in geoserver security audits).

So we have a choice of:

  • changing this back, or
  • using hazelcast to sort out sessions across the cluster; or
  • asking you to set up your load balancer to direct all gui interaction to a single node

Can I ask you if the third option works (even as a workaround). And we should report this to Jira :frowning:

–
Jody Garnett

–
Jody Garnett

On 27 April 2016 at 17:25, Amiram Rahav arahav@anonymised.com wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

OWASP also suggests that checking the Origin header is a reasonably effective solution: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token

Seems like forms (doing POST requests) need CSRF protection, I’m not sure what a link (GET) needs it for? In fact, this is an anti-pattern described on the OWASP page “Disclosure of token in URL”…

Rob :slight_smile:

···

On 28 April 2016 at 20:16, Jody Garnett <jody.garnett@anonymised.com> wrote:

Checking the wiki (and spreadsheet) I could not quickly find the specific configuration change that is intended to randomize generated URLs. The issue comes up each-time-we-get-a-security-audit … although we do not particularly battle harden our administration UI (as we intend people to use the webservices on mass rather than the layer preview screen). I get the impression security audit companies have automated tools that review website pages and point out a list of common mistakes such as this one:

The general story is that each link or action should point to a new URL generated for that sessions to prevent some categories of attack, here is an example of such a report:

Web Application Vulnerable To Crosssite Request Forgery Attacks: Recommend that the web application be modified to check that a request has come from a user-generated process, such as completing a form or clicking a link. In effect, each transaction to be processed should carry a unique ID value. In addition, it is recommended that all functions only transmit their data via POST requests and that when each form is accessed, a random value be set. This random value should then be added to the form (normally via a hidden field) and as a value within the user’s session on the server-side. When the application processes the required POST, it should check that the value hidden in the form and the value stored within the user’s session are the same; if they are not, the request should be rejected.

Some background for wicket:

TLDR: The wicket solution to this is to use KeyInSessionSunJceCryptFactory for forms (rather than a hidden field) resulting in encrypted URLs.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

–
Jody Garnett

On 28 April 2016 at 08:30, Amiram Rahav <arahav@anonymised.com> wrote:

Hi Jody,

Could you go into more detail about what security risk(s) does unique wicket URLs mitigate? Frankly it’s difficult to see how this adds much to security - as soon as you know how this behaves it would be trivial to deal with a 302 and a unique wicket URL from an attack standpoint.

The third option doesn’t really work with AWS ELBs. There isn’t an easy way to route all traffic based on a URL match to a single instance, which means this will require another layer of indirection to configure routing rules.
Session stickiness can be used, but then that also affects REST and OGC calls and isn’t optimal.

Also what you describe is, to a degree, what JMS clustering is where we have one management node and multiple worker nodes. But that requires more infrastructure, and a slave JMS node could act as a master which would more likely than not get us back to this issue.

Option 2 is a given - hazelcast is used for session sharing across cluster nodes, perhaps it should also be used to deal with unique URLs, however the HTTP 302 on every UI interaction is still an issue…

My 2 cents is that option 1 - reverting this change would make the most sense.

I hope other people will chime in…

Thanks,

Ami.

On Wednesday, April 27, 2016, Jody Garnett <jody.garnett@anonymised.com> wrote:

First up thanks for testing - it is appreciated. I do not thing this was done on purpose, other than we were trying an option for unique wicket URLs (something that comes up in geoserver security audits).

So we have a choice of:

  • changing this back, or
  • using hazelcast to sort out sessions across the cluster; or
  • asking you to set up your load balancer to direct all gui interaction to a single node

Can I ask you if the third option works (even as a workaround). And we should report this to Jira :frowning:

–
Jody Garnett

On 27 April 2016 at 17:25, Amiram Rahav arahav@anonymised.com wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Chief Technical Officer Koordinates

+44 759 987 3480 / koordinates.com / @koordinates

6

On 28-04-16 02:48, Jody Garnett wrote:

And we should report this to Jira :frowning:

https://osgeo-org.atlassian.net/browse/GEOS-7526

I am working on reproducing the issue.

Regards
Niels

7

So as suspected this is a consequence of wicket7 upgrade. The generated id preserves the state of the page and prevents the "double submit problem" to occur.

The feature can be turned off with a simple setting to make it clustering compatible. However that will imply that refreshing a page will cause it to loose its status and that users may be confronted with the double submit problem.

I see three possible solutions:

1. turn it off for everyone
2. allow the clustering plug-ins to turn it off programmatically
3. make it fully user configurable

What is the preferred choice?

Cheers
Niels

On 29-04-16 14:19, Niels Charlier wrote:

On 28-04-16 02:48, Jody Garnett wrote:

  And we should report this to Jira :frowning:

https://osgeo-org.atlassian.net/browse/GEOS-7526

I am working on reproducing the issue.

Regards
Niels

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

8

We discussed this on the meeting and decided to combine option (2) and (3). Let the default setting be changed programmatically by the clustering modules, but also provide a fully configurable option to the user.

I have a PR ready at https://github.com/geoserver/geoserver/pull/1589

Regards
Niels

On 02-05-16 18:37, Niels Charlier wrote:

So as suspected this is a consequence of wicket7 upgrade. The generated
id preserves the state of the page and prevents the "double submit
problem" to occur.

The feature can be turned off with a simple setting to make it
clustering compatible. However that will imply that refreshing a page
will cause it to loose its status and that users may be confronted with
the double submit problem.

I see three possible solutions:

1. turn it off for everyone
2. allow the clustering plug-ins to turn it off programmatically
3. make it fully user configurable

What is the preferred choice?

Cheers
Niels

On 29-04-16 14:19, Niels Charlier wrote:

On 28-04-16 02:48, Jody Garnett wrote:

   And we should report this to Jira :frowning:

https://osgeo-org.atlassian.net/browse/GEOS-7526

I am working on reproducing the issue.

Regards
Niels

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

9

Hey Niels,
Thank you for taking the time and working on this!

Just tested today’s build and noticed that POSTs are still using unique wicket IDs, which causes various issues with the UI. Would it be possible to disable unique IDs for POST requests as well?

Thanks!

Ami.

···

On Thu, Apr 28, 2016 at 3:26 PM, Robert Coup <robert.coup@anonymised.com> wrote:

OWASP also suggests that checking the Origin header is a reasonably effective solution: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token

Seems like forms (doing POST requests) need CSRF protection, I’m not sure what a link (GET) needs it for? In fact, this is an anti-pattern described on the OWASP page “Disclosure of token in URL”…

Rob :slight_smile:

On 28 April 2016 at 20:16, Jody Garnett <jody.garnett@anonymised.com> wrote:

Checking the wiki (and spreadsheet) I could not quickly find the specific configuration change that is intended to randomize generated URLs. The issue comes up each-time-we-get-a-security-audit … although we do not particularly battle harden our administration UI (as we intend people to use the webservices on mass rather than the layer preview screen). I get the impression security audit companies have automated tools that review website pages and point out a list of common mistakes such as this one:

The general story is that each link or action should point to a new URL generated for that sessions to prevent some categories of attack, here is an example of such a report:

Web Application Vulnerable To Crosssite Request Forgery Attacks: Recommend that the web application be modified to check that a request has come from a user-generated process, such as completing a form or clicking a link. In effect, each transaction to be processed should carry a unique ID value. In addition, it is recommended that all functions only transmit their data via POST requests and that when each form is accessed, a random value be set. This random value should then be added to the form (normally via a hidden field) and as a value within the user’s session on the server-side. When the application processes the required POST, it should check that the value hidden in the form and the value stored within the user’s session are the same; if they are not, the request should be rejected.

Some background for wicket:

TLDR: The wicket solution to this is to use KeyInSessionSunJceCryptFactory for forms (rather than a hidden field) resulting in encrypted URLs.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Chief Technical Officer Koordinates

+44 759 987 3480 / koordinates.com / @koordinates

–
Jody Garnett

On 28 April 2016 at 08:30, Amiram Rahav <arahav@anonymised.com> wrote:

Hi Jody,

Could you go into more detail about what security risk(s) does unique wicket URLs mitigate? Frankly it’s difficult to see how this adds much to security - as soon as you know how this behaves it would be trivial to deal with a 302 and a unique wicket URL from an attack standpoint.

The third option doesn’t really work with AWS ELBs. There isn’t an easy way to route all traffic based on a URL match to a single instance, which means this will require another layer of indirection to configure routing rules.
Session stickiness can be used, but then that also affects REST and OGC calls and isn’t optimal.

Also what you describe is, to a degree, what JMS clustering is where we have one management node and multiple worker nodes. But that requires more infrastructure, and a slave JMS node could act as a master which would more likely than not get us back to this issue.

Option 2 is a given - hazelcast is used for session sharing across cluster nodes, perhaps it should also be used to deal with unique URLs, however the HTTP 302 on every UI interaction is still an issue…

My 2 cents is that option 1 - reverting this change would make the most sense.

I hope other people will chime in…

Thanks,

Ami.

On Wednesday, April 27, 2016, Jody Garnett <jody.garnett@anonymised.com> wrote:

First up thanks for testing - it is appreciated. I do not thing this was done on purpose, other than we were trying an option for unique wicket URLs (something that comes up in geoserver security audits).

So we have a choice of:

  • changing this back, or
  • using hazelcast to sort out sessions across the cluster; or
  • asking you to set up your load balancer to direct all gui interaction to a single node

Can I ask you if the third option works (even as a workaround). And we should report this to Jira :frowning:

–
Jody Garnett

On 27 April 2016 at 17:25, Amiram Rahav arahav@anonymised.com wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10

Hello Ami,

Are you sure about this? I tested this and it was not the case with me. I just got a 302 after a post that leads back to the home page, which is normal, but no id.

Regards
Niels

On 20-05-16 04:04, Amiram Rahav wrote:

Hey Niels,
Thank you for taking the time and working on this!

Just tested today's build and noticed that POSTs are still using unique wicket IDs, which causes various issues with the UI. Would it be possible to disable unique IDs for POST requests as well?

Thanks!

Ami.

On Thu, Apr 28, 2016 at 3:26 PM, Robert Coup <robert.coup@anonymised.com <mailto:robert.coup@anonymised.com>> wrote:

    OWASP also suggests that checking the Origin header is a
    reasonably effective solution:
    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token
    <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token&gt;

    Seems like forms (doing POST requests) need CSRF protection, I’m
    not sure what a link (GET) needs it for? In fact, this is an
    anti-pattern described on the OWASP page “Disclosure of token in URL”…

    Rob :slight_smile:

    On 28 April 2016 at 20:16, Jody Garnett <jody.garnett@anonymised.com
    <mailto:jody.garnett@anonymised.com>> wrote:

        Checking the wiki
        <https://github.com/geoserver/geoserver/wiki/Wicket-migration-code-sprint&gt;
        (and spreadsheet
        <https://docs.google.com/spreadsheets/d/1yzE9W4ZaIUcmE1XRcHCTih2mLEhMhVoZxKQl_k1n7D8/edit?ts=569d2137#gid=0&gt;\)
        I could not quickly find the specific configuration change
        that is intended to randomize generated URLs. The issue comes
        up each-time-we-get-a-security-audit ... although we do not
        particularly battle harden our administration UI (as we intend
        people to use the webservices on mass rather than the layer
        preview screen). I get the impression security audit companies
        have automated tools that review website pages and point out a
        list of common mistakes such as this one:

        The general story is that each link or action should point to
        a new URL generated for that sessions to prevent some
        categories of attack, here is an example of such a report:

            /*Web Application Vulnerable To Crosssite Request Forgery
            Attacks: *//Recommend that the web application be modified
            to check that a request has come from a user-generated
            process, such as completing a form or clicking a link. In
            effect, each transaction to be processed should carry a
            unique ID value. In addition, it is recommended that all
            functions only transmit their data via POST requests and
            that when each form is accessed, a random value be set.
            This random value should then be added to the form
            (normally via a hidden field) and as a value within the
            user’s session on the server-side. When the application
            processes the required POST, it should check that the
            value hidden in the form and the value stored within the
            user’s session are the same; if they are not, the request
            should be rejected./

        Some background for wicket:
        -
        http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html
        - http://issues.apache.org/jira/browse/WICKET-1782

        TLDR: The wicket solution to this is to use
        KeyInSessionSunJceCryptFactory for forms (rather than a hidden
        field) resulting in encrypted URLs.

        --
        Jody Garnett

        On 28 April 2016 at 08:30, Amiram Rahav
        <arahav@anonymised.com <mailto:arahav@anonymised.com>> wrote:

            Hi Jody,

            Could you go into more detail about what security risk(s)
            does unique wicket URLs mitigate? Frankly it's difficult
            to see how this adds much to security - as soon as you
            know how this behaves it would be trivial to deal with a
            302 and a unique wicket URL from an attack standpoint.

            The third option doesn't really work with AWS ELBs. There
            isn't an easy way to route all traffic based on a URL
            match to a single instance, which means this will require
            another layer of indirection to configure routing rules.
            Session stickiness can be used, but then that also affects
            REST and OGC calls and isn't optimal.

            Also what you describe is, to a degree, what JMS
            clustering is where we have one management node and
            multiple worker nodes. But that requires more
            infrastructure, and a slave JMS node could act as a master
            which would more likely than not get us back to this issue.

            Option 2 is a given - hazelcast is used for session
            sharing across cluster nodes, perhaps it should also be
            used to deal with unique URLs, however the HTTP 302 on
            every UI interaction is still an issue...

            My 2 cents is that option 1 - reverting this change would
            make the most sense.

            I hope other people will chime in...

            Thanks,
            Ami.

            On Wednesday, April 27, 2016, Jody Garnett
            <jody.garnett@anonymised.com <mailto:jody.garnett@anonymised.com>>
            wrote:

                First up thanks for testing - it is appreciated. I do
                not thing this was done on purpose, other than we were
                trying an option for unique wicket URLs (something
                that comes up in geoserver security audits).

                So we have a choice of:

                - changing this back, or
                - using hazelcast to sort out sessions across the
                cluster; or
                - asking you to set up your load balancer to direct
                all gui interaction to a single node

                Can I ask you if the third option works (even as a
                workaround). And we should report this to Jira :frowning:

                --
                Jody Garnett

                On 27 April 2016 at 17:25, Amiram Rahav
                <arahav@anonymised.com> wrote:

                    Hey Guys,

                    Trying out 2.9 Beta2 with Hazelcast clustering I
                    noticed that every UI request results with an HTTP
                    302 response and a unique ID appended to the URL.
                    when using a single instance this isn't that big
                    of an issue, however when having multiple
                    instances behind a load balancer this results with
                    multiple redirects, which causes the UI to be
                    unusable.(In most cases the browser will just give
                    up).
                    In some cases this can also become an issue with a
                    single instance behind a proxy.

                    Looking around I wasn't able to find the commit
                    that added that change, but I'm guessing this was
                    done as part of the wicket upgrade.

                    Anyone knows if this was this was done in response
                    to a specific issue, or just as an artifact of the
                    wicket upgrade?
                    Would it be possible to change this behavior back
                    to something that resembles 2.8 (eg HTTP 200 and
                    non unique IDs)?

                    Thanks,
                    Ami.

                    ------------------------------------------------------------------------------
                    Find and fix application performance issues faster
                    with Applications Manager
                    Applications Manager provides deep performance
                    insights into multiple tiers of
                    your business applications. It resolves
                    application problems quickly and
                    reduces your MTTR. Get your free trial!
                    https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
                    _______________________________________________
                    Geoserver-devel mailing list
                    Geoserver-devel@lists.sourceforge.net
                    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

        ------------------------------------------------------------------------------
        Find and fix application performance issues faster with
        Applications Manager
        Applications Manager provides deep performance insights into
        multiple tiers of
        your business applications. It resolves application problems
        quickly and
        reduces your MTTR. Get your free trial!
        https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
        _______________________________________________
        Geoserver-devel mailing list
        Geoserver-devel@lists.sourceforge.net
        <mailto:Geoserver-devel@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/geoserver-devel

    --

    Chief Technical Officer Koordinates

    +44 759 987 3480 <tel:+44%20759%209873480> / koordinates.com
    <http://koordinates.com/&gt;/ @koordinates
    <https://twitter.com/koordinates&gt;

11

Hey Niels,

Yes, as an example trying to create a store will have a POST that looks like this: geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?**20-1.**IFormSubmitListener-storeForm, while it should look like this:
geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?IFormSubmitListener-storeForm.

This is also true when modifying layers, deleting workspaces, etc…

Thanks,

Ami.

···

On Fri, May 20, 2016 at 3:52 AM, Niels Charlier <niels@anonymised.com> wrote:

Hello Ami,

Are you sure about this? I tested this and it was not the case with me. I just got a 302 after a post that leads back to the home page, which is normal, but no id.

Regards
Niels

On 20-05-16 04:04, Amiram Rahav wrote:

Hey Niels,
Thank you for taking the time and working on this!

Just tested today’s build and noticed that POSTs are still using unique wicket IDs, which causes various issues with the UI. Would it be possible to disable unique IDs for POST requests as well?

Thanks!

Ami.

On Thu, Apr 28, 2016 at 3:26 PM, Robert Coup <robert.coup@anonymised.com> wrote:

OWASP also suggests that checking the Origin header is a reasonably effective solution: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token

Seems like forms (doing POST requests) need CSRF protection, I’m not sure what a link (GET) needs it for? In fact, this is an anti-pattern described on the OWASP page “Disclosure of token in URL”…

Rob :slight_smile:

On 28 April 2016 at 20:16, Jody Garnett <jody.garnett@anonymised.com> wrote:

Checking the wiki (and spreadsheet) I could not quickly find the specific configuration change that is intended to randomize generated URLs. The issue comes up each-time-we-get-a-security-audit … although we do not particularly battle harden our administration UI (as we intend people to use the webservices on mass rather than the layer preview screen). I get the impression security audit companies have automated tools that review website pages and point out a list of common mistakes such as this one:

The general story is that each link or action should point to a new URL generated for that sessions to prevent some categories of attack, here is an example of such a report:

Web Application Vulnerable To Crosssite Request Forgery Attacks: Recommend that the web application be modified to check that a request has come from a user-generated process, such as completing a form or clicking a link. In effect, each transaction to be processed should carry a unique ID value. In addition, it is recommended that all functions only transmit their data via POST requests and that when each form is accessed, a random value be set. This random value should then be added to the form (normally via a hidden field) and as a value within the user’s session on the server-side. When the application processes the required POST, it should check that the value hidden in the form and the value stored within the user’s session are the same; if they are not, the request should be rejected.

Some background for wicket:

TLDR: The wicket solution to this is to use KeyInSessionSunJceCryptFactory for forms (rather than a hidden field) resulting in encrypted URLs.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Chief Technical Officer Koordinates

+44 759 987 3480 / koordinates.com / @koordinates

–
Jody Garnett

On 28 April 2016 at 08:30, Amiram Rahav <arahav@anonymised.com> wrote:

Hi Jody,

Could you go into more detail about what security risk(s) does unique wicket URLs mitigate? Frankly it’s difficult to see how this adds much to security - as soon as you know how this behaves it would be trivial to deal with a 302 and a unique wicket URL from an attack standpoint.

The third option doesn’t really work with AWS ELBs. There isn’t an easy way to route all traffic based on a URL match to a single instance, which means this will require another layer of indirection to configure routing rules.
Session stickiness can be used, but then that also affects REST and OGC calls and isn’t optimal.

Also what you describe is, to a degree, what JMS clustering is where we have one management node and multiple worker nodes. But that requires more infrastructure, and a slave JMS node could act as a master which would more likely than not get us back to this issue.

Option 2 is a given - hazelcast is used for session sharing across cluster nodes, perhaps it should also be used to deal with unique URLs, however the HTTP 302 on every UI interaction is still an issue…

My 2 cents is that option 1 - reverting this change would make the most sense.

I hope other people will chime in…

Thanks,

Ami.

On Wednesday, April 27, 2016, Jody Garnett <jody.garnett@anonymised.com> wrote:

First up thanks for testing - it is appreciated. I do not thing this was done on purpose, other than we were trying an option for unique wicket URLs (something that comes up in geoserver security audits).

So we have a choice of:

  • changing this back, or
  • using hazelcast to sort out sessions across the cluster; or
  • asking you to set up your load balancer to direct all gui interaction to a single node

Can I ask you if the third option works (even as a workaround). And we should report this to Jira :frowning:

–
Jody Garnett

On 27 April 2016 at 17:25, Amiram Rahav <arahav@anonymised.com> wrote:

Hey Guys,

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.

when using a single instance this isn’t that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).

In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn’t able to find the commit that added that change, but I’m guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?

Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,

Ami.

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

12

Hello Ami,

I see what you mean, I thought you were referring to the 302 redirecting still, but in this case the ID is already in the form action URL from the beginning. In your example, the "20" is indeed a page ID, the part after the dash referring to the component.

However, this ID is necessary because the form action needs to executed on the specific page object. Otherwise we would be needing to use StatelessForms instead of normal Forms all over geoserver, which means we can only use data that was posted inside the Form and nothing on the page that is stored in the session. I seriously doubt that the code base is compatible with that at all, this could mean a massive refactoring of the WebUI for which we'd need at least a week-long code sprint :slight_smile:

But this shouldn't be necessary, as far as I can find out, it is only the redirect strategy that poses a problem for clustering (https://ci.apache.org/projects/wicket/guide/7.x/guide/redirects.html).

However - the question is, has clustering actually been set up properly for wicket? Are we properly sharing the wicket session between the instances? Do we perhaps have to do something like this:
http://mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/

Kind Regards
Niels

On 20-05-16 17:20, Amiram Rahav wrote:

Hey Niels,

Yes, as an example trying to create a store will have a POST that looks like this: geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?*20-1.*IFormSubmitListener-storeForm, while it should look like this:
geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?IFormSubmitListener-storeForm.

This is also true when modifying layers, deleting workspaces, etc..

Thanks,
Ami.

On Fri, May 20, 2016 at 3:52 AM, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:

    Hello Ami,

    Are you sure about this? I tested this and it was not the case
    with me. I just got a 302 after a post that leads back to the home
    page, which is normal, but no id.

    Regards
    Niels

    On 20-05-16 04:04, Amiram Rahav wrote:

    Hey Niels,
    Thank you for taking the time and working on this!

    Just tested today's build and noticed that POSTs are still using
    unique wicket IDs, which causes various issues with the UI. Would
    it be possible to disable unique IDs for POST requests as well?

    Thanks!

    Ami.

    On Thu, Apr 28, 2016 at 3:26 PM, Robert Coup
    <robert.coup@anonymised.com
    <mailto:robert.coup@anonymised.com>> wrote:

        OWASP also suggests that checking the Origin header is a
        reasonably effective solution:
        https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token

        Seems like forms (doing POST requests) need CSRF protection,
        I’m not sure what a link (GET) needs it for? In fact, this is
        an anti-pattern described on the OWASP page “Disclosure of
        token in URL”…

        Rob :slight_smile:

        On 28 April 2016 at 20:16, Jody Garnett
        <jody.garnett@anonymised.com> wrote:

            Checking the wiki
            <https://github.com/geoserver/geoserver/wiki/Wicket-migration-code-sprint&gt;
            (and spreadsheet
            <https://docs.google.com/spreadsheets/d/1yzE9W4ZaIUcmE1XRcHCTih2mLEhMhVoZxKQl_k1n7D8/edit?ts=569d2137#gid=0&gt;\)
            I could not quickly find the specific configuration
            change that is intended to randomize generated URLs. The
            issue comes up each-time-we-get-a-security-audit ...
            although we do not particularly battle harden our
            administration UI (as we intend people to use the
            webservices on mass rather than the layer preview
            screen). I get the impression security audit companies
            have automated tools that review website pages and point
            out a list of common mistakes such as this one:

            The general story is that each link or action should
            point to a new URL generated for that sessions to prevent
            some categories of attack, here is an example of such a
            report:

                /*Web Application Vulnerable To Crosssite Request
                Forgery Attacks: *//Recommend that the web
                application be modified to check that a request has
                come from a user-generated process, such as
                completing a form or clicking a link. In effect, each
                transaction to be processed should carry a unique ID
                value. In addition, it is recommended that all
                functions only transmit their data via POST requests
                and that when each form is accessed, a random value
                be set. This random value should then be added to the
                form (normally via a hidden field) and as a value
                within the user’s session on the server-side. When
                the application processes the required POST, it
                should check that the value hidden in the form and
                the value stored within the user’s session are the
                same; if they are not, the request should be rejected./

            Some background for wicket:
            -
            http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html
            - http://issues.apache.org/jira/browse/WICKET-1782

            TLDR: The wicket solution to this is to use
            KeyInSessionSunJceCryptFactory for forms (rather than a
            hidden field) resulting in encrypted URLs.

            --
            Jody Garnett

            On 28 April 2016 at 08:30, Amiram Rahav
            <arahav@anonymised.com> wrote:

                Hi Jody,

                Could you go into more detail about what security
                risk(s) does unique wicket URLs mitigate? Frankly
                it's difficult to see how this adds much to security
                - as soon as you know how this behaves it would be
                trivial to deal with a 302 and a unique wicket URL
                from an attack standpoint.

                The third option doesn't really work with AWS ELBs.
                There isn't an easy way to route all traffic based on
                a URL match to a single instance, which means this
                will require another layer of indirection to
                configure routing rules.
                Session stickiness can be used, but then that also
                affects REST and OGC calls and isn't optimal.

                Also what you describe is, to a degree, what JMS
                clustering is where we have one management node and
                multiple worker nodes. But that requires more
                infrastructure, and a slave JMS node could act as a
                master which would more likely than not get us back
                to this issue.

                Option 2 is a given - hazelcast is used for session
                sharing across cluster nodes, perhaps it should also
                be used to deal with unique URLs, however the HTTP
                302 on every UI interaction is still an issue...

                My 2 cents is that option 1 - reverting this change
                would make the most sense.

                I hope other people will chime in...

                Thanks,
                Ami.

                On Wednesday, April 27, 2016, Jody Garnett
                <jody.garnett@anonymised.com> wrote:

                    First up thanks for testing - it is appreciated.
                    I do not thing this was done on purpose, other
                    than we were trying an option for unique wicket
                    URLs (something that comes up in geoserver
                    security audits).

                    So we have a choice of:

                    - changing this back, or
                    - using hazelcast to sort out sessions across the
                    cluster; or
                    - asking you to set up your load balancer to
                    direct all gui interaction to a single node

                    Can I ask you if the third option works (even as
                    a workaround). And we should report this to Jira :frowning:

                    --
                    Jody Garnett

                    On 27 April 2016 at 17:25, Amiram Rahav
                    <arahav@anonymised.com> wrote:

                        Hey Guys,

                        Trying out 2.9 Beta2 with Hazelcast
                        clustering I noticed that every UI request
                        results with an HTTP 302 response and a
                        unique ID appended to the URL.
                        when using a single instance this isn't that
                        big of an issue, however when having multiple
                        instances behind a load balancer this results
                        with multiple redirects, which causes the UI
                        to be unusable.(In most cases the browser
                        will just give up).
                        In some cases this can also become an issue
                        with a single instance behind a proxy.

                        Looking around I wasn't able to find the
                        commit that added that change, but I'm
                        guessing this was done as part of the wicket
                        upgrade.

                        Anyone knows if this was this was done in
                        response to a specific issue, or just as an
                        artifact of the wicket upgrade?
                        Would it be possible to change this behavior
                        back to something that resembles 2.8 (eg HTTP
                        200 and non unique IDs)?

                        Thanks,
                        Ami.

                        ------------------------------------------------------------------------------
                        Find and fix application performance issues
                        faster with Applications Manager
                        Applications Manager provides deep
                        performance insights into multiple tiers of
                        your business applications. It resolves
                        application problems quickly and
                        reduces your MTTR. Get your free trial!
                        https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
                        _______________________________________________
                        Geoserver-devel mailing list
                        Geoserver-devel@lists.sourceforge.net
                        https://lists.sourceforge.net/lists/listinfo/geoserver-devel

            ------------------------------------------------------------------------------
            Find and fix application performance issues faster with
            Applications Manager
            Applications Manager provides deep performance insights
            into multiple tiers of
            your business applications. It resolves application
            problems quickly and
            reduces your MTTR. Get your free trial!
            https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
            _______________________________________________
            Geoserver-devel mailing list
            Geoserver-devel@lists.sourceforge.net
            <mailto:Geoserver-devel@lists.sourceforge.net>
            https://lists.sourceforge.net/lists/listinfo/geoserver-devel

        --

        Chief Technical Officer Koordinates

        +44 759 987 3480 <tel:+44%20759%209873480> / koordinates.com
        <http://koordinates.com/&gt;/ @koordinates
        <https://twitter.com/koordinates&gt;

13

On Sun, May 22, 2016 at 10:59 AM, Niels Charlier <niels@anonymised.com> wrote:

However - the question is, has clustering actually been set up properly
for wicket? Are we properly sharing the wicket session between the
instances?

Going by memory, only the hazelcast clustering module in community land has
support
for clustering the wicket session (I did not write the module, could be
wrong).

This clustering module is meant to be used with the jdbc configuration
backend, I'm not sure
it is at all compatible with the JMS clustering one.
For JMS clustering we normally suggest to setup sticky sessions for the web
UI instead,
or if a single master node approach is chosen, setup the load balancer so
that any access
to the /web path goes only to the master node.

Hope this helps.

Cheers
Andrea

--

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.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

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.

-------------------------------------------------------

14

How did it work before? Were we using stateless forms before (relying only on session for security credentials)?

I am wondering if this is a new regression, or only one that has been detected now.

···

On Sun, May 22, 2016 at 10:59 AM, Niels Charlier <niels@anonymised.com> wrote:

However - the question is, has clustering actually been set up properly for wicket? Are we properly sharing the wicket session between the instances?

Going by memory, only the hazelcast clustering module in community land has support
for clustering the wicket session (I did not write the module, could be wrong).

This clustering module is meant to be used with the jdbc configuration backend, I’m not sure
it is at all compatible with the JMS clustering one.
For JMS clustering we normally suggest to setup sticky sessions for the web UI instead,
or if a single master node approach is chosen, setup the load balancer so that any access
to the /web path goes only to the master node.

Hope this helps.

Cheers
Andrea

–

==
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.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

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.

15

On Sun, May 22, 2016 at 6:23 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

How did it work before? Were we using stateless forms before (relying only
on session for security credentials)?

No, we always had significant stateful portions (every complex page
actually)

I am wondering if this is a new regression, or only one that has been
detected now.

Could also be a mismatch in expectation, as said, in the JMS clustering
plugin we don't cluster
the UI and expect the load balancer to be setup in such a way that a single
node is hit for the
admin UI.

For the hazelcast one, I see there is some code to cluster the wicket
session across nodes,
this indicates at least an intention to allow freeform load balancing for
the UI as well... whether
it works/used to work or not, I don't know personally.

Cheers
Andrea

--

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.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

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.

-------------------------------------------------------