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.garn...@gmail.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 :(
>
> --
> Jody Garnett
>
> On 27 April 2016 at 17:25, Amiram Rahav <ara...@boundlessgeo.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
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to